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Zusammenfassung: Ohne auf wesentliche Aspekte der in [Bergstra&al.89] vorgestellten algebraischen 
Spezifikationssprache ASF zu verzichten, haben wir ASF um die folgenden Konzepte erweitert: Während 
in ASF einmal exportierte Namen bis zur Spitze der Modulhierarchie sichtbar bleiben müssen, ermöglicht 
ASF+ ein differenziertes Verdecken von Signaturnamen. Das fehlerhafte Vermischen unterschiedlicher 
Strukturen, welches in ASF beim Import verschiedener Aktualisierungen desselben parametrisierten Mo- 
duls auftritt, wird in ASF+ durch eine adäquatere Form der Parameterbindung vermieden. Das neue 
Namensraum-Konzept von ASF+ erlaubt es dem Spezifizierer, einerseits die Herkunft verdeckter Namen 
direkt zu identifizieren und anderseits beim Import eines Moduls auszudrücken, ob dieses Modul nur benutzt 
oder in seinen wesentlichen Eigenschaften verändert werden soll. Im ersten Fall kann er auf eine einzige glo- 
bal zur Verfügung stehende Version zugreifen; im zweiten Fall muß er eine Kopie des Moduls importieren. 
Schließlich erlaubt ASF+ semantische Bedingungen an Parameter und die Angabe von Beweiszielen. 



Diese Arbeit ist aus einer von Klaus Madiener und Claus-Peter Wirth betreuten Projektarbeit Rüdiger Lundes her- 
vorgegangen und wurde gefördert von der Deutschen Forschungsgemeinschaft, SFB 314 (D4-Projekt). 



Abstract: Maintaining the main aspects of the algebraic specification language ASF as presented in [Berg- 
stra&al.89] we have extend ASF with the foUowing concepts: While once exported names in ASF must stay 
visible up to the top the module hierarchy, ASF+ permits a more sophisticated hiding of signature names. 
The erroneous merging of distinct structures that occurs when importing different actualizations of the same 
parameterized module in ASF is avoided in ASF+ by a more adequate form of parameter binding. The new 
"Namensraum"-concept of ASF+ permits the specifier on the one band directly to identify the origin of 
hidden names and on the other to decide whether an imported module is only to be accessed or whether 
an important property of it is to be modified. In the first case he can access one single globally provided 
Version; in the second he has to import a copy of the module. Finally ASF+ permits semantic conditions on 
Parameters and the specification of tasks for a theorem prover. 
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1 Einleitung 

Mit steigender Leistungsfähigkeit modemer automatischer Beweissysteme wächst auch die Kom- 
plexität der mit ihnen zu bearbeitenden Problemstellungen. Auf der Suche nach Konzepten zur 
logisch strukturierten Formulierung derartiger Probleme haben sich in der Entwicklung von Spe- 
zifikationssprachen Modularisierungsansätze herausgebildet. Eine Spezifikation besteht danach 
aus mehreren Modulen, die mit Hilfe von Importbefehlen aufeinander Bezug nehmen. Besonders 
in umfangreichen Spezifikationen erweisen sich modulare Repräsentationen von Spezifikationen 
als vorteilhaft. Die Verständlichkeit wird durch die Zerlegung in einzelne, durch exakt definierte 
Schnittstellen (Importkonstrukte) miteinander verbundene Teilspezifikationen gesteigert. Außer- 
dem können häufig verwendete Strukturen (beispielsweise die Datenstruktur Boolean) in Biblio- 
theken abgelegt werden, was den Spezifikationsaufwand reduziert. 

Verschiedene Möglichkeiten, Module miteinander zu kombinieren, werden in dieser Arbeit 
diskutiert. Das Hauptinteresse gilt der Entwicklung einer Sprache für modulare Spezifikationen 

mit positiv/negativ bedingten Gleichungen. Ausgehend von der in [Bergstra&al.89] vorgestellten 
Sprache ASF, die bereits über ein recht differenziertes Modularisierungskonzept verfügt, wird 
eine Erweiterung ASF+ vorgestellt, welche die im ersten und vorvorletzten Punkt von "1.4.1. 
Known defects and limitations of ASF" in [Bergstra&al.89] genannten Mängel von ASF behebt. 
ASF+ unterstützt: 

• Import und Parametrisierung von Modulen 

• Überladen von Funktionsnamen 

• Infix- Operatoren 

• differenziertes Verdecken von Funktions- und Sortennamen 

• positiv/negativ bedingte Gleichungen 

• rudimentäre Verwaltung von Beweiszielen 

Als Semantik wird, analog zu [Bergstra & al. 89], semi-formal eine Normalisierungsproze- 
dur angegeben, welche die Modulhierachie einer komplexen Spezifikation in eine flache Spezi- 
fikation (ohne Importe) umwandelt. Von zentraler Bedeutung ist in diesem Zusammenhang die 
Originfunktion, die jedem in der Spezifikation auftretenden Namen einen Informationsblock zu- 
weist. Dieser enthält für den Normalisierungsprozeß wichtige Informationen über den Kontext der 
Namensdefinition, beispielsweise den Namen des Definitionsmoduls. Neben der Originfunktion 
verwaltet die Normalisierungsprozedur aus ASF"*" eine Dependenzfunktion. Sie spielt bei expli- 
ziten Umbenennungen und Parameterbindungen eine wichtige Rolle und trägt der hierarischen 
Struktur der Spezifikation Rechnung. Neu in ASF+ ist auch, daß bei der Kombination von Modu- 
len das Umbenennen von verdeckten Namen nicht ausschließlich durch Konfliktfreiheit definiert 
wird. Jeder verdeckte Name beinhaltet in ASF+ unter anderem das Kürzel des Herkunftsmoduls, 
was zum einen Konfliktfreiheit garantiert, zum andern auch modulare Information sichtbar macht 
und damit der Übersicht dient. 
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2 Das Konzept, erklärt anhand von Beispielspezifikationen 



Um mit der Syntax von ASF+ vertraut zu werden und ein erstes intuitives Verständnis der neuen 

Sprache zu gewinnen, bietet es sich an, zunächst einige Beispielspezifikationen zu betrachten. 
Die hier angegebenen Module Booleans, Naturais und Sequences entsprechen im we- 
sentlichen den gleichnamigen Modulen aus [Bergstra & al. 89], Kapitel 1.1.2., was einen direkten 
Vergleich erlaubt. 



2.1 Bottom-Up-Spezifikationen 

module Booleans 

Short Bo 

{ 

add signature 
{ public: 
sort s 

BOOL 
constructors 

true, false : -> BOOL 

non-const ructors 

and, or : BOOL # BOOL -> BOOL 

private : 

non-const ructors 

not : BOOL -> BOOL } 

variables 

{ non-constructors 

x,y : -> BOOL } 

equations 

{ 

macro-equation and(x,y) 
{ 

case 

{ ( X @ true ) : y 

( X @ false ) : false } 

} 

macro-equation not (x) 
{ 

case 

{ ( X @ true ) : false 
( X @ false ) : true } 

} 
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[el] or (x, y) = not (and (not (x) , not (y) ) ) 

} 

} /* Booleans */ 

Jedes Modul einer Spezifikation beginnt mit dem Schlüsselwort module, gefolgt vom Mo- 
dulnamen, dem optionalen short-Konstrukt und einem Block. Das short-Konstrukt stellt ein 
Modulnamenkürzel zur Verfügung, das beim Umbenennen verdeckter Namen Verwendung findet 
und zumindest bei langen Modulnamen nicht fehlen sollte. Fehlt die Angabe des Modulkürzels, 
so wird der Modulname selbst ersatzweise als sein eigenes Kürzel verwendet. Die Kürzel werden 
global zur Bezeichnung der Module herangezogen und müssen daher innerhalb der Spezifikation 
eindeutig sein. 

Alle nicht importierten Teile der Signatur werden mit dem add signature-Konstrukt zur 
internen Signatur zusammengefaßt. Sie umfaßt einen nach außen sichtbaren (public) und einen 
nur innerhalb des Moduls zugänglichen (private) Bereich, in denen Sorten- und Funktions- 
namen deklariert werden können. Da der Spezifikationssemantik ein konstruktorbasierter Ansatz 
zu Grunde liegt (vergleiche etwa [Wirth&Gramlich93] oder [Wirth&Gramlich94]), wird zwi- 
schen constructors und non-constructors unterschieden. Im Beispiel sind die Sorte 
BOOL, die Konstanten true, f alse und die (Prädikats-) Funktionen and, or nach außen sicht- 
bar (können also von anderen Modulen importiert werden), not wird zu Illustrationszwecken 
nicht exportiert, und kann infolgedessen nur innerhalb des Moduls referenziert werden. 

Im Beispiel folgt eine Variablenvereinbarung, die jeder im Gleichungsblock verwendeten Va- 
riable eine Sorte zuweist. Die Overloadingfähigkeit von ASF+ (d.h. die Möglichkeit namens- 
gleiche Funktionen mit verschiedenen Argumentsorten zu unterscheiden) macht eine Deklarati- 
on aller Variablen zwingend notwendig. ASF+ unterscheidet zwischen Konstruktor- und Non- 
Konstruktor-Variablen, die durch die Schlüsselwörter constructors und non-construc- 
tors gekennzeichnet werden. Defaultwert ist constructors. Werden nur Konstruktor- Variablen 
verwendet, so kann deshalb das Schlüsselwort (wie in den folgenden Beispielen) entfallen. 

ASF"*" unterstützt Spezifikationen mit positiv/negativ bedingten Gleichungen. Sie können im 
Gleichungsblock entweder explizit angegeben werden (im Beispiel die Zeile mit Marke el) 
oder mit Hilfe des macro-equation-Konstrukts erzeugt werden. Das macro-equat ion- 
Konstrukt geht aus dem macro-rule-Konstrukt aus [Wirth&Lunde94] hervor und unter- 
scheidet sich nur durch die C-ähnliche Syntax. Seine Semantik ist durch Makro-Expansion in 
positiv/negativ bedingte Gleichungen gegeben. Eine wichtige Rolle spielen sogenannte match- 
conditions (Symbolisiert durch @), mit deren Hilfe Gleichungen, deren linke Seiten mit dem glei- 
chen Funktionssymbol beginnen, zusammengefaßt werden können. Im Beispiel führt die Makro- 
Expansion zu den vier Gleichungen 

[me-andl] and (true, y) = y 
[me-and2] and(false, y) = false 
[me-notl] not (true) = false 

[me-not2] not (false) = true 

Bei umfangreichen Funktionsdefinitionen bietet die Darstellung als macro-equat Ion große 
Vorteile, weil durch verschachtelte case-Konstrukte zahlreiche Wiederholungen von Bedingun- 
gen eingespart werden können. Für die genaue Bedeutung der Makros @, case, if und eise 
sei auf [Wirth&Lunde94] verwiesen. 
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Alle verwendeten Variablen und Marken werden semantisch wie private-deklarierte Si- 
gnatumamen behandelt und müssen nur innerhalb des Moduls eindeutig sein. 



module Naturais 

Short Nat 

{ 

Import Booleans { public: BOOL, true, false } 

add signature 
{ 

public : 
sort s 

NAT 

constructors 

: 

s : NAT 

non-constructors 

_ + _ : NAT # NAT 

eq : NAT # NAT 

} 

variables 

{ x,y,u : -> NAT } 

equations 
{ 

macro-equation (x + y) 
{ 

case 

{ ( y @ ) : X 

( y @ s (u) ) : s (x + u) } 

} 

macro-equation eq(x,y) 
{ if ( X = y ) true 

eise false } 

} 

} /* Naturais */ 



-> NAT 

-> NAT 

-> NAT 

-> BOOL 



Das Modul Naturais importiert das Modul Booleans. Der Block, der dem Importbefehl 
folgt, trägt der Forderung nach einem flexiblen Lokalitätsprinzip Rechnung. Er sorgt dafür, daß 
nur die im Block aufgeführten Namen im Modul zugänglich sind. Im Beispiel sind die Sorte 
BOOL und die Konstanten true und false innerhalb des Moduls Naturais sichtbar und 
werden auch von ihm exportiert. Die von Booleans exportierten, aber im Importkonstrukt nicht 
aufgeführten Funktionen and und or und die nicht exportierte Funktion not können innerhalb 
von Naturais nicht referenziert werden. Ihre Namen gelten als verdeckt (hidden). 
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Unter den im add signature-Konstrukt deklarierten Funktionssymbolen befindet sich 
auch der Infix-Operator "+". Seine Deklarationssyntax wurde, wie auch die der Präfix-Operatoren, 
aus ASF übernommen. 

module OrdNaturals 

Short ONat 

{ 

Import Booleans 

{ public: BOOL, true; private: or } 

Import Naturais 

{ public: NAT, 0, s, eq, false } 

add signature 
{ public: 

non-const ruct ors 

greater, geq: NAT # NAT -> BOOL } 

variables 

{ x,y,u,v : -> NAT } 

equations 
{ 

macro-equation greater (x,y) 



case 



( X @ ) 

( X @ s (u) , y @ ) 
( X @ s (u) , y @ s (v) 



true 



greater (u, v) 



false 



[el] 



geq(x,y) = or (greater (x, y) , eq(x,y)) 



goals 



[irref] greater (x, x) 



— > 



[trans] greater (x, u) , greater (u, y) 

--> greater (x, y) 

[total] 

— > greater (x, y) , greater (y, x) , x = y } 



} /* OrdNaturals */ 
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OrdNaturals spezifiziert eine irreflexive Ordnung greater und eine reflexive Ordnung 
geq für Elemente des Typs NAT. Der doppelte Import des Moduls Booleans (direkt und indi- 
rekt über Naturais) demonstriert, daß die Sichtbarkeit von Namen eines importierten Moduls 
im allgemeinen nicht von einem Importbefehl allein abhängt. So wäre es falsch, aus dem Fehlen 
des Namens f al se im ersten Importblock abzuleiten, daß f al se innerhalb von OrdNatural s 
verdeckt sein muß. 

Der goal s-Block am Ende von OrdNatural s ermöglicht es dem Spezifizierer, Beweiszie- 
le anzugeben. Jede Beweisaufgabe besteht aus einer in eckigen Klammem eingefaßten Marke, ge- 
folgt von einer Gentzenklausel. Syntaktisch handelt es sich dabei um eine Folge von durch Kom- 
mas getrennte Gleichungen, gefolgt von einem Pfeil und einer weiteren Folge von Gleichungen. 
Semantisch ist die Gentzenformel Ci, . . . , e„ — > e„+i, . . . , e„+m equivalent zu Ci A . . . A e„ — > 
e„_|_i V ... V Cn+m- Gleichungen der Form P{xi, . . . , Xn) = t rue können wie im Beispiel durch 
P(xi, . . . , Xn) abgekürzt werden. Syntaktisch korrekt ist eine solche abgekürzte Gleichung je- 
doch nur dann, wenn t rue innerhalb des Moduls sichtbar und sortengleich mit der Zielsorte von 
P ist. In ASF+ werden alle Beweisziele exportiert. Auf Flags zur Beschränkung der Sichtbarkeit, 
wie sie in ART [Eschbach94] Verwendung finden, wird verzichtet. ASF+ versteht sich als Einga- 
beschnittstelle zu einem Beweiser, nicht als Ausgabeschnittstelle. Deshalb wird auch auf solche 
Flags verzichtet, die Auskunft darüber geben, welche der Klauseln als bewiesen gelten dürfen und 
welche nicht. Der Stempel "proved" ohne einen Verweis auf den Beweis, ist ohnehin von zwei- 
felhaftem Wert, zumal kaum überprüft werden kann, ob die Spezifikation nach setzen des Flags 
vom Benutzer verändert wurde. Es wird davon ausgegangen, daß der Beweiser für die bearbeitete 
Spezifikation eine Datei anlegt, die Informationen über die Spezifikation enthält (zum Beispiel 
den Namen des Top-Moduls und Datum+Zeit der letzten Spezifikationsmodifikation) und neben 
allen bewiesenen Theoremen auch Referenzen auf die Beweise beinhaltet. 
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2.2 Parametrisierte Module 

Die bisher eingeführten Konstrukte erscheinen ausreichend für Bottom-Up-Spezifikationen. Wünschens- 
wert sind jedoch auch Mechanismen, die es gestatten, Freiräume innerhalb eines Modules zu 
erhalten, die erst später (z. B. beim Import des Moduls in ein weiteres) mit konkretem Inhalt 
gefüllt werden müssen. Das Parameterkonzept von ASF+ gestattet es, Sorten und Funktionen in 
ein parametrisiertes Modul nachträglich durch Parameterbindung zu "implantieren". Als Beispiel 
betrachten wir das Modul Sequences, in dem Sequenzen von nicht näher spezifizierten Ele- 
menten definiert werden. Als Konstruktoren dienen nil (erzeugt die leere Sequenz) und cons 
(fügt ein Element an eine Sequenz an). 

module Sequences <(ITEMpar)> 

Short Seq 

{ 

add signature 
{ 

Parameters : 
( sorts 

ITEMpar ) 
public : 
sorts 
SEQ 

constructors 

nil : -> SEQ 

cons : ITEMpar # SEQ -> SEQ 

} 

} /* Sequences 

In ASF+ müssen alle formalen Parameter (ob importiert, oder wie im Beispiel im add s ignat ure- 
Konstrukt deklariert) an prominenter Stelle direkt hinter dem Modulnamen in spitzen Klammem 
angegeben werden. Beim Auftreten mehrerer Parameter kann mit Hilfe der runden Klammern 
die Zahl der möglichen Parameterbindungen eingeschränkt werden. Alle Parameter eines durch 
runde Klammem eingefaßten Tupels dürfen nur an Namen desselben Moduls gebunden werden. 

Auch OrdSequences (unten) spezifiziert Sequenzen über eine durch Bindung des Parame- 
ters ITEMpar zu präzisierende Sorte von Elementen. In Frage kommen hier jedoch nur Sorten, 
für die eine irreflexive Ordnung spezifiziert wurde. Mit Hilfe dieser Ordnung wird eine lexiko- 
graphische Ordnung auf Sequenzen definiert. 

module OrdSequences < (ITEMpar, ordpar) > 

Short OSeq 

{ 

Import Booleans {public: BOOL, true, false} 

add signature 
{ 

Parameters : 
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( sorts 

ITEMpar 
non-const ruct ors 

ordpar : ITEMpar # ITEMpar -> BOOL 
conditions 

[irref] ordpar (il, il) 
— > 

[trans] ordpar (il, i2) , ordpar (12, 13) 

--> ordpar (11, 13) 
[total] 

— > ordpar (11, 12 ) , ordpar (12, 11) , 11 = 12 

) 

public : 

sorts 
SEQ 

constructors 

nll : -> SEQ 

cons : ITEMpar # SEQ -> SEQ 

non-const ruct ors 

greater : SEQ # SEQ -> BOOL 

} 

variables 

{ 11, 12, 13 : -> ITEMpar 

seql, seq2, sl, s2 : -> SEQ } 

equatlons 
{ 

macro-equatlon greater (seql, seq2) 

{ /* lex-order on sequences */ 

case 

{ 

( seql @ nll ) : false 

( seql @ cons (11, sl), seq2 @ nll ) : true 
( seql @ cons (11, sl), seq2 @ cons (12, s2) ): 
If ( ordpar(ll, 12) ) 
true 

eise If ( 11 = 12 ) 

greater(sl, s2) 
eise 

false 

} 

} 

} 

} /* OrdSequences */ 

ASF+ verzichtet im Gegensatz zu ASF auf die Einführung eines formalen Parameters für den 
Modulnamen, an den ein Parameter-Tupel gebunden wird. Als Parameter werden in ASF"*" statt 
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dessen die Sorten- und Funktionsnamen innerhalb der Parameter-Tupel bezeichnet. Die Gruppie- 
rung der Parameter in Blöcke (hier Tupel, dargestellt durch runde Klammem) wird jedoch bei- 
behalten, weil sie sich bei der Formulierung semantischer Bedingungen als vorteilhaft erweist. 
Funktionsparameter können nicht überladen werden. 

Unter "semantischen Bedingungen" verstehen wir in ASF+ Gentzenklauseln, die in der Defi- 
nition eines Parameter- Tupels im Parameterteil des add signatur-Konstrukts angegeben wer- 
den können (hier irref, trans und total). Die Zulässigkeit der Bindung eines Parameter- 
Tupels an Namen eines Moduls Mact hängt nun davon ab, ob die aus der Bindung hervorgehen- 
den Gentzenklauseln innerhalb von Mact gelten oder nicht. Da dieses Problem im allgemeinen 
unentscheidbar ist wird zusätzlich gefordert, daß Mact Beweisziele enthält, die sich nur durch 
die Marken- und Variablennamen von den Bedingungsklauselinstanzen unterscheiden und für die 
bereits Beweise existieren. Mit Bedingungen verknüpfte Parameter-Tupel können nur an Namen 
solcher Module gebunden werden, die keine ungebundenen Parameter mehr enthalten, weil für 
Module mit freien Parametern (bisher) keine Semantik innerhalb des ASF- Ansatzes existiert. 

Mit dem Konzept der semantischen Bedingungen werden vor allem zwei Ziele verfolgt: Einer- 
seits werden semantisch unsinnige Parameterbindungen schon in der Akzeptanzphase der Spezi- 
fikation erkannt, außerdem können diese Bedingungen in parametrisierten Beweisen als Lemmas 
von Bedeutung sein, weil sie die "wesentlichen" Eigenschaften der Parameter enthalten. 

Beim Import eines parametrisierten Moduls sind alle Parametertupel hinter dem Modulnamen 
in eckigen Klammem aufzuführen: 

Import OrdSequences <(ITEMpar, ordpar) > 
{ public: SEQ, nil, cons } 

Da Parameter nicht verdeckt werden können, entspricht diese Syntax dem Grundsatz, daß alle 
innerhalb eines Moduls sichtbaren Namen dort auch angegeben werden müssen. 

2.3 Das Namensraumkonzept 

Eine Gmndidee des flexiblen Verdeckungsmechanismus aus ASF+ ist die eindeutige Zuordnung 
von Namen zu Namensräumen. Im wesentlichen beschreibt der Namensraum das Modul, in dem 
der Name zum ersten Mal in Erscheinung tritt (im Folgenden als Definitionsmodul bezeichnet). 
Im Beispiel Naturais gehören unter anderem NAT und dem Namensraum Naturais und 
BOOL und true dem Namensraum Booleans an. Der Name x kommt in beiden Namensräum- 
en als Variable in unterschiedlicher Bedeutung vor. Ein Namensraum umfaßt also alle inner- 
halb eines Moduls eingeführten Namen (einschließlich Marken) abzüglich der importierten. Die 
Namen eines Moduls gehören im allgemeinen also verschiedenen Namensräumen an. Wir be- 
zeichnen den Namensraum, dem die im Modul definierten Namen angehören, als den modulei- 
genen Namensraum (er erbt auch den Namen des Moduls), alle anderen heißen importierte Na- 
mensräume. Namen aus verschiedenen Importbefehlen können nur dann miteinander identifiziert 
werden, wenn sie dem gleichen Namensraum angehören, was bei mehrfachem Import desselben 
Moduls der Fall sein kann. Was geschieht aber, wenn Namen Namensräumen von Modulen an- 
gehören, die durch Renaming oder Parameterbindung beim Import "manipuliert" wurden? ASF+ 
löst das Problem durch Schaffung neuer Namensrauminstanzen, die Kopien der ursprünglichen 
Namensräume repräsentieren. Das Kopieren einzelner Namen aus ASF wird durch gruppenwei- 
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ses Kopieren ersetzt, deren kleinste Einheiten die Namensräume bilden. Die schwerwiegenden 
Gründe für diese konzeptionelle Entscheidung werden im Kapitel 4.2 diskutiert. 

2.4 Explizites Renaming 

Unter explizitem Renaming verstehen wir in ASF+ das Umbenennen von Signatur- und Parame- 
temamen aus importierten Modulen mit Hilfe des renamed to-Konstrukts. 

module Integers 

Short Int 

{ 

Import Naturais [ Int 1 ] 

{ public: NAT renamed to INT, 0, s, +, eq } 

add signature { public: constructors p : INT -> INT } 

variables { x, y : -> INT } 

equations 

{ [el] s (p(x) ) = X 
[e2] p (s (x) ) = X 
[e3] p(x) + y = p(x + y) } 

} /* Integers */ 

Integers spezifiziert den Datentyp der ganzen Zahlen unter Verwendung der natürlichen 
Zahlen. In ASF+ wird erwartet, daß jeder Importbefehl, in dem ein explizites Renaming oder ei- 
ne Parameterbindung vorgenommen wird, eine innerhalb der Spezifikation eindeutige (möglichst 
kurze) Instanzbezeichnung (im Beispiel Int 1) beinhaltet. Sie wird gebraucht, um Namen unter- 
schiedlich instanziierter Namensräume zu unterscheiden. 

Im letzten Beispiel gehören u. a. INT, und s dem neuen Namensraum Natural s [ Int 1 ] 
an. Naturais [Intl] ist dabei eine Instanz (bzw. Kopie) des Namensraumes Naturais, 
die durch das explizite Renaming im Importbefehl geschaffen wurde. Natürlich können auch 
instanziierte Namesräume bei einem weiteren Import manipuliert werden: 

Import Integers [ Int2 ] { public : INT renamed to INTnew } 

INTnew gehört, wie auch beispielsweise der hier nicht mehr sichtbare Name 0, nun dem 
Namensraum Naturais [ Int 1 , Int2 ] an. 

Die hierachische Struktur einer Spezifikation bedingt Abhängigkeiten zwischen Namensräum- 
en. Im Beispiel führt die Umbenennung von INT des Namensraumes Naturais [ Int 1 ] nach 
INTnew auch zu einer Änderung der Konstruktordeklaration für p des Namensraumes Integers 
(Definitions- und Wertebereich werden geändert), der Namensraum Booleans bleibt dagegen 
unbeeinflußt. ASF"*" trägt diesem Umstand Rechnung, indem der Konstruktor p und die Varia- 
blen X und y aus Integers dem neuen Namensraum Integers [ Int 2 ] zugeordnet werden. 
BOOL gehört nach wie vor dem Namensraum Booleans an. Allgemein hängt ein moduleigener 
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Namensraum von allen importierten Namensräumen ab, was bei der Modifikation von Namen 
aus indirekt importierten Modulen zur Instanziierung mehrerer Namensräume führt. 

Jede Instanzbezeichnung darf innerhalb einer Spezifikation nur ein einziges mal verwendet 
werden. Da zwischen Modulkürzeln und Instanzbezeichnungen keine Verwechselungsgefahr be- 
steht, bietet es sich an, das Modulkürzel als Instanzbezeichnung wiederzuverwenden, sofern im 
Modul nur ein instanziierender Import vorgenommen wird. 



2.5 Parameterbindungen 

module OrdNatSequences 

Short ONSeq 

{ 

Import OrdSequences [ONSeq] <(ITEMpar bound to NAT, 

ordpar bound to greater) of OrdNaturals ; 
{ public: SEQ renamed to NSEQ, 

nil renamed to Nnil, 

cons, greater, 

BOOL, true, false } 

Import OrdNaturals 

{ public: NAT, greater, 0, s } 

} 



Analog zu ASF werden Parameter blockweise an ein Modul gebunden. Semantisch gesehen 
bedeutet die Bindung von Parametern eines Moduls Mform (im Beispiel OrdSeqences) an 
Namen eines Moduls Mact (im Beispiel OrdNaturals) einerseits, daß Parametemamen aus 
Mform durch Namen aus Mact ersetzt werden. Letztere können entweder exportierbare Signa- 
tumamen oder Parameter sein. Da sie jedoch nur im Kontext des Moduls Mact eine Bedeutung 
besitzen, müssen andererseits beide Module miteinander kombiniert werden. Der Importblock, 
der der Parameterbindung folgt, bestimmt ausschließlich die Sichtbarkeit der Signaturnamen des 
Moduls Mform- Explizites Renaming ist zulässig. Die Signatumamen des Moduls Mact (auch 
die aktuellen Parameter selbst, sofern sie nicht wieder Parameter sind) gelten im bindenden Mo- 
dul (im Beispiel OrdNatSequences) als verdeckt, es sei denn, ein weiterer (direkter) Import 
nimmt wie im Beispiel Einfluß auf die Sichtbarkeit einzelner Namen. Explizites Renaming ist 
in diesem Falle jedoch kaum sinnvoll, weil sonst die Signatumamen des zusätzlich importierten 
Moduls aufgrund der unterschiedlichen Namensrauminstanzen nicht mit denen aus Mact iden- 
tifiziert werden. 

Genau wie das explizite Renaming führt auch das Binden von Parametern zur Instanziierung 
der direkt betroffenen und aller davon abhängigen Namensräume. Um auch ohne den direkten 

Import von Mact eine vollständige Signatur zu garantieren, sorgt die Semantik der Parameter- 
bindung dafür, daß neben dem Modul Mform auch automatisch Mact (verdeckt) in das bin- 
dende Modul importiert wird — ein Vorgang, der im folgenden als impliziter Import bezeichnet 
wird. 



12 



greater kann als Demonstrationsbeispiel für eine überladene Funktion gesehen werden. In 
OrdNatSequences referenziert der Name sowohl eine irreflexive Ordnung auf den natürlichen 
Zahlen als auch auf Sequenzen. 

Da jede Parameterbindung zu einer Instanziierung des Namensraumes der zu bindenden Pa- 
rameter und aller davon abhängigen Namensräume bis hin zum Modul MpoRM führt (diese Na- 
mensräume fallen zusammen, falls wie in unseren Beispielen MpoRM die Parameter selbst defi- 
niert, also nicht importiert), ist es auch möglich, Module "an sich selbst" zu binden, ohne daß es 
zu einer unerwünschten Vermischung der dort eingeführten Strukturen kommt. 

SeqOf Seq spezifiziert Sequenzen von Elementen, die selbst Sequenzen sind. Um Namens- 
kollisionen zwischen Signatumamen der Module Mpqrm und Mact zu vermeiden ist eine die 
Umbenennung aller Sorten und Konstanten, deren Sichtbarkeit im bindenden Modul erwünscht 
ist (im Beispiel SEQ und nil) zwingend notwendig. Die sowohl aus MpoRM als auch aus Mact 
importierten Konstruktoren cons unterscheiden sich in ihren Argumentsorten und dürfen daher 
überladen werden. 

module SeqOfSeq <(ITEMpar)> 

Short SOS 

{ 

Import Sequences [SOS] <( ITEMpar bound to SEQ ) 

of Sequences < (ITEMpar) > > 
{ public: SEQ renamed to SEQl, 

nil renamed to nill, 

cons } 

Import Sequences < (ITEMpar) > 
{ public: SEQ, nil, cons } 

} 



3 Strukturdiagramme 
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Die modulare Struktur von ASF"*"- Spezifikationen kann mit Hilfe von Strukturdiagrammen ver- 
anschaulicht werden. Alle Namen innerhalb eines importfreien Moduls gehören demselben (mo- 
duleigenen) Namensraum an. Er wird durch ein Rechteck, genannt Namensraumbox dargestellt, 
in dem zentriert unter der Oberkante die Namensraumbezeichnung (= Modulname) steht. 



Booleans 



Enthält das darzustellende Modul Importbefehle, so kann der Import durch ineinander ver- 
schachtelte Boxen dargestellt werden. Sie symbolisieren die hierarchische Struktur der Namensräume, 
die im Modul, dessen moduleigener Namensraum durch die äußerste Box gegeben ist, eine Rolle 
spielen. Ein Namensraum ist von allen Namensräumen abhängig, die seine Box umschließt. 



Naturais 
Booleans 



Im add signatur-Konstrukt eines Moduls enthaltene Parametertupel werden oberhalb 
der Boxen für importierte Namensräume in Sechsecken aufgeführt. 

ürüSequences 
ITEMpar, ordpar ^ 
I Booleans 1 



Werden beim Import Namen eines Moduls geändert oder Parameter gebunden, führt das in 
ASP"*" dazu, daß alle direkt betroffenen, sowie die davon abhängigen Namensräume mit der In- 
stanzbezeichnung des Importbefehls instanziiert werden. Eine fehlerhafte Identifikation von Na- 
men aus diesen manipulierten Räumen mit den "Originalen" ist dadurch ausgeschlossen. 





mtegers 




Naturais Llntl J 




Booleans 
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Das Binden von Parametern eines Moduls Mform (im Bsp. OrdSequence) an Namen 
eines weiteren Moduls Mact (im Beispiel OrdNaturals) wird durch einen Pfeil angedeutet. 
Die Richtung des Pfeils verdeutlicht die Abhängigkeit zwischen den Namensräumen der Module 
Mact und Mform- Der instanziierte Namensraum der zu bindenden Parameter sowie alle von 
ihm abhängigen Namensräume hängen von jedem in Mact enthaltenen Namensraum ab. 





ürcLNatSequences 




ürcLSequences LüNSeqJ 
-— ^^TEMpar, ordpar ^ 






OrdNaturals 




Naturais 




Booleans 






Booleans 






OrdNaturals 




Naturais 




Booleans 






Booleans 











Da neben dem impliziten, durch die Parameterbindung verursachten Import von Mact ein 
zusätzlicher (direkter) Import erforderlich ist, um Signatumamen aus Mact für das bindende 
Modul sichtbar zu machen führen wir eine kompaktere Darstellung ein, in der wir den impliziten 
und den direkten Import (falls vorhanden) zu einer Box zusammenfassen. 





ürdNatSequences 




OrdSequences LONSeqJ 
— ^^TEMpar, ordpar ^ 






OrdNaturals 




Naturais 




Booleans 




Booleans 
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Erweitert werden können die ASF+ -Strukturdiagramme durch Hinzunahme der Signatur. Je- 
des Modul zerfällt zunächst in zwei Bereiche. Links stehen die sichtbaren, rechts die verdeckten 
Signatumamen. Der linke Bereich der sichtbaren Namen zerfällt seinerseits in zwei Sichtbarkeits- 
stufen: Neben den public-deklarierten Namen, die vom betreffenden Modul exportiert wer- 
den können (auf die also importierende Module zugreifen können), gibt es noch die private- 
deklarierten Namen, welche nur innerhalb des Moduls sichtbar sind und auch nur dort referenziert 
werden können. Insgesamt existieren also die drei Bereiche "public", "private" und "hidden", die 
durch zwei gepunktete senkrechte Trennungslinien dargestellt werden können. 



OrdNaturals 



Naturais : 


Bool'eans 

false BOOL and 
true or 


not 




NAT + 



s 

eq 











Booleans 






BOOL 


or 




and 


not : 


true 






false 





greater 
geq 



Im Beispiel sind innerhalb von Naturais die Namen NAT, 0, s, eq, + und die importier- 
ten Namen false, BOOL, true sichtbar. Nach dem Import in OrdNaturals bleiben davon 
zunächst lediglich die Namen NAT, 0, s, eq und false übrig. +, BOOL, und true werden 
hier hingegen nicht sichtbar. Der zweite Import des Moduls Booleans sorgt dafür, daß auch 
für OrdNaturals BOOL und true sichtbar sind. Hauptzweck dieses Imports ist es jedoch, 
die Referenzierbarkeit von or für OrdNaturals zu erreichen, was beim indirekten Import 
über Naturais nicht möglich war. Am Beispiel wird deutlich, daß bei mehrfachem Import 
desselben Moduls ein Name in unterschiedlichen Sichtbarkeitsstufen auftreten kann und wird. 
Die Sichtbarkeit im importierenden Modul richtet sich bei ASF+ in diesem Fall nach der größten 
importierten Sichtbarkeit (Auftreten am weitesten links im Strukturdiagramm). Gleichnamige Pa- 
rameter, gleichnamige Sorten sowie gleichnamige Funktionen mit gleichen Argumentsorten, die 
innerhalb eines Moduls sichtbar sind und unterschiedlichen Namensräumen angehören, stellen 
einen Namenskonflikt, also einen Spezifikationsfehler, dar. 
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4 Semantik hierarchischer Konzepte 

Für hierarchische Konzepte algebraischer Spezifikationssprachen sind grundsätzlich zwei Seman- 
tikansätze denkbar: 



• Jedes Modul erhält eine Semantik. Die Semantik einer hierarchisch modularisierten Spezi- 
fikation errechnet sich aus den einzelnen Modulsemantiken. 



• Nur für elementare (flache) Spezifikationen wird eine algebraische Semantik definiert. Hier- 
archischen Spezifikationen wird mit Hilfe eines Normalform- Algorithmus eine elementare 
Spezifikation zugewiesen, deren Semantik die Semantik der hierarchischen Spezifikation 
definiert. Die Bedeutung der Importkonstrukte ist hier eine auf der Syntax von Spezifikati- 
onsmodulen und nicht auf deren Semantiken definierte Funktion. 



Obwohl hinsichtlich der Modularisierung von Beweisen die erste Variante interessante Per- 
spektiven bietet, fällt unsere Wahl aufgrund der hohen Komplexität und der vielen offenen Fragen 
in bezug auf praktische Adäquatheit einer geeigneten Modulsemantik auf die zweite. Ein Vorteil 
dieser auch bei ASF angewandten Vorgehensweise ist die gute Operationalisierbarkeit. Von zen- 
traler Bedeutung ist die Normalisierungsprozedur, da mit ihr (indirekt) die Semantik der einzel- 
nen Importbefehle festgelegt wird. Im folgenden sollen grundsätzliche Möglichkeiten beleuchtet, 
Schwachstellen der ASF-Semantik erläutert und Alternativen aufgezeigt werden. 



4.1 Der "benutzende" Import 

Lassen wir zunächst das Verdeckungskonzept außer acht und verzichten außerdem auf die Möglich- 
keit, Funktionen zu überladen. Dann kann man sich die Bedeutung eines renamingfreien Im- 
portbefehls ohne Parameterbindungen in erster Näherung als eine "komponentenweise" Verei- 
nigung des importierten Moduls mit dem importierenden Modul vorstellen. Die Sortennamen- 
menge des resultierenden Moduls ergibt sich als Vereinigungsmenge der Sortennamen des im- 
portierten und des importierenden Moduls. Gleiches gilt für Konstruktor- und Non-Konstruktor- 
Funktionsdeklarationen, Parametertupel, Variablendeklarationen, Gleichungen, Beweisziele und, 
mit Ausnahme des gerade ausgewerteten Importbefehls (der nun gelöscht werden kann), auch für 
die Importbefehle. Der Modulname des resultierenden Moduls ist durch die komponentenweise 
Vereinigung nicht festgelegt. Die Normalform einer mit Hilfe solcher Importbefehle hierarchisch 
strukturierten Spezifikation berechnet sich dann als komponentenweise Vereinigung aller direkt 
und indirekt importierten Module mit dem Top-Modul. Die Reihenfolge, mit der die Importbe- 
fehle eleminiert werden, spielt dabei für das resultierende Normalformmodul keine Rolle. Ein 
Spezifikationsfehler liegt vor, wenn bei der Vereinigung ein inkorrektes Modul erzeugt wird. 
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Alternativ können die Importbefehle eines Moduls auch in zwei Schritten eleminiert wer- 
den: Zunächst werden die importierten Module untereinander und danach das Zwischenresultat 

mit dem importierenden Modul "vereinigt". Dieses Vorgehen liefert bei der bisher betrachteten 
eingeschränkten Form von Importbefehlen das gleiche Resultat. Die Vereinigung der Import- 
befehlmenge muß in diesem Fall sinngemäß modifiziert werden: Bei der komponentenweisen 
Vereinigung im ersten Schritt (wir schreiben |J) müssen alle Importbefehle der vereinigten (im- 
portierten) Module im Zwischenresultat berücksichtigt werden, während im zweiten Schritt (hier 
schreiben wir U) nur die Importbefehle des Zwischenresultats (und nicht die des importierenden 
Moduls) in das Resultat übernommen werden dürfen. 

Dies erlaubt nun die folgende Operationalisierung der Vereinigungssemantik, welche den Vor- 
teil hat, daß alle Zwischenergebnisse Normalformen sind, was bei der Behandlung von verdeckten 
Namen von Vorteil ist. 



• Die Normalform eines importfreien Moduls ist das Modul selbst. 



• Die Normalform eines Moduls M, welches Mi, ... , Mn importiert ergibt sich aus der kom- 
ponentenweisen Vereinigung der Normalformen von Mi, . . . , M„ und M. 



Wir schreiben: 

M falls M importfrei 

NF(M) :=( ^ y y NF (Mi) falls Mi, . . . , M„ von M importiert werden. 

i=l 

Die Vereinigungssemantik ist invariant gegenüber mehrfachem Import des gleichen Moduls, 
auch ist die Reihenfolge der Importe ohne Bedeutung. Entscheidend bleibt lediglich, welche Mo- 
dule importiert werden. Diese Eigenschaften sind typisch für eine bestimmte Art von Importen, 
die wir "benutzende Importe" nennen. 

Die Einfachheit der Vereinigungssemantik wird jedoch mit einem schweren Defekt erkauft. 

Sie identifiziert Sorten und Funktionsdeklarationen aus verschiedenen Herkunftsmodulen im Fal- 
le zufälliger syntaktischer Gleichheit, auch wenn sie nichts miteinander zu tun haben. Nur wenige 
Konflikte zwischen Modulen, die den gleichen Namen in unterschiedlicher Bedeutung benutzen, 
werden erkannt. 

Eine modifizierte Version der "Vereinigungssemantik" sollte also prüfen, ob es innerhalb der 
Spezifikation einen Namen gibt, der in zwei Modulsignaturen unterschiedlich definiert wird. In 
diesem Fall (wir gehen von sichtbaren, nicht überladbaren Namen aus) liegt ein Namenskonflikt 
vor. Diese Modifikation kann auf die rekursive Variante nicht ohne weiteres übertragen werden, 
da den Signaturnamen der Normalformen der zu importierenden Module nicht direkt angesehen 
werden kann, welchem Modul sie ihre Entstehung verdanken. 
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Ml 






M2 

A 






M3 

A 







Ml' 



M2' 






M4' 

A 









M3' 



M4' 



In obigem Beispiel tritt der Sortenname A sowohl links in den Signaturen der Normalformen 
von M2 und M3 (sie sind bereits in Normalform) als auch rechts in den Signaturen der Normal- 
formen von M2 und M3 auf. Während dies in Mi zu einem Namenskonflikt führt, können in 
M[ beide Namen identifiziert werden, da sie aus der gleichen Definition in M4 hervorgegangen 
sind. Den Normalformmodulen ist das jedoch nicht mehr zu entnehmen. ASF löst das Problem 
durch Einführung einer Originfunktion. Sie weist jedem Signatumamen einen Informationsblock 
(Origin) zu, der u. a. den Namen des Moduls enthält, welches für die Definition des Namens ver- 
antwortlich ist. Tritt in zwei zu importierenden Normalformmodulen der gleiche Signatumame 
auf, kann anhand der zugeordneten Origins entschieden werden, ob es sich um einen Namens- 
konflikt handelt oder nicht. 

Ein modifizierter Normalformalgorithmus könnte folgendermaßen aussehen: Sei {Mj | 1 < 
i < n} die Menge der vom Spezifizierer erzeugten Module einer Spezifikation, modui der Name 
des Moduls Mi und {signi .j \ l < j < rrii} die Menge aller Signatumamen des Moduls Mj. 
Wir definieren zu jedem Modul eine Originfunktion 

Uri : {sign^ j \ 1 <j < m^} — > {modrii} 
Uvi :— {sign^ j \ 1 < j < rrii) x {modrii). 

Die Normalform eines Moduls Mj errechnet sich rekursiv wie folgt: 

{Mi, Uri) falls Mi importfrei 

Pi Pi 

{Mi U y M^, , C/r, U IJ o-, ) falls Mi die Module Mi>^ importiert und 
' ' {M[,,o[,)^ NF{Mi,)li\i{l<k<Pi). 



NF{Mi) :-- 



Pi 



Ein Namenskonflikt liegt genau dann vor, wenn {UviD y o-, ) keine Funktion ist 



k=l 



Der angegebene Algorithmus liefert genau die Semantik renamingfreier Importe ohne Para- 
meterbindung für sichtbare nicht überladene Namen aus ASF bzw. ASF+. 
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4.2 Der "kopierende" Import 

Besonders in großen Spezifikationen wird es häufig zu Namenskonflikten kommen, weil die Zahl 
der Namen mit jedem neuen Modul wächst. Würde das Auflösen solcher Konflikte das Edieren 
der verantwortlichen Module erzwingen, zöge das gleichzeitig Namensänderungen in allen Mo- 
dulen nach sich, die auf das edierte Modul zugreifen. Der Spezifizierer hätte bei der Erstellung 
eines neuen Moduls darauf zu achten, daß alle neu eingeführten Namen in keinem anderen bisher 
vorhandenen Modul verwendet werden, was der Konzeption des modularen Spezifizierens nicht 
entspricht. Deshalb stellt ASF ein Renamingkonstrukt zur Verfügung, welches das Umbenennen 
von Namen beim Import ermöglicht. Leider führt jedoch die ASF-Bedeutung dieses Konstrukts 
zum Vermischen unterschiedlicher Strukturen, wie das folgende ASF-Beispiel zeigt: 



module exA 
begin 

export s 

begin sorts A 

f unct ions 

mk_A : -> A 

end 
end exA 



Die Anweisung " Imports exA { renamed by [mk_A -> make_A] } " bedeutet 
in ASF den Import eines Moduls namens exA, das sich vom Original exA dadurch unterschei- 
det, daß jedes Auftreten vom Signatumamen mk_A durch make_A ersetzt wurde. Das erscheint 
sinnvoll, solange innerhalb einer Spezifikation nur mit einer Version des Moduls gearbeitet wird. 
Äußerst unschön erweist sich die Semantik jedoch beim Import mehrerer Varianten eines Moduls: 



Module Murks 
begin 

imports exA, 

exA { renamed by [mk_A -> make_A] } 

end Murks 



Die Semantik von ASF kann zwischen beiden Instanzen des importierten Moduls exA nicht 
unterscheiden, was dazu führt, daß Murks über zwei Konstruktoren für die Sorte A verfügt. Das 
namenweise Kopieren kann in größeren Spezifikationen leicht dazu führen, daß Namen, die nicht 
direkt am expliziten Renaming beteiligt sind, fälschlich miteinander identifiziert werden. 
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Zu derartig unmotivierten Namensidentifikationen kommt es in ASF auch beim Import ver- 
schiedener, durch Parameterbindungen aktuaUsierter Versionen des gleichen Moduls. Als Demon- 
strationsbeispiel untersuchen wir Sequenzen über natürlichen Zahlen und Boole'schen Werten in 
ASF: 



module Sequences 
begin 

Parameters 

Items begin 

sorts ITEM 
end Items 

export s 
begin 

sorts SEQ 

functions nil : -> SEQ 

cons: ITEM # SEQ -> SEQ 

end 

end Sequences 



module Auwei 
begin 

imports Sequences 

{ Items bound by [ITEM -> NAT] to Naturais }, 
Sequences 

{ Items bound by [ITEM -> BOOL] to Booleans } 

end Auwei 



Die Module Naturais und Booleans seien sinngemäß (analog zu den gleichnamigen 
ASF+ -Modulen) definiert. Das Modul Auwei importiert zwei verschiedene Arten von Sequen- 
zen. Beide Arten tragen jedoch den gleichen Sortennamen SEQ, was eigentlich einen Namenskon- 
flikt erwarten ließe. Statt dessen werden jedoch von ASF beide Sorten miteinander identifiziert, 
was dazu führt, daß cons (s (0) , cons (true, nil) ) als wohlsortierter Term der Sorte 
SEQ akzeptiert wird. Dies entspricht sicherlich nicht den Vorstellungen des Spezifizierers! 

Lassen wir weiterhin verdeckte Namen und Overloading außer acht, dann kann das Renaming 
aus ASF als Erweiterung der modifizierten Vereinigungssemantik gesehen werden: 



21 



{Mi, ÜTi) falls Mi importfrei 

Pi Pi 

NFiM ) ■= l (^i U □ Ri'^{M[,^), Un U U Ri'^{o'i,^)) falls Mi die Module M,. impor- 

^ *^=i ^==1 tiert und {M'., ,o'-,) = NF {Mi' ) 

k k ^ 

gilt(l<A;<Pi). 

Hier ist Ri'^ eine Funktion, die Signatumamen des zu importierenden Moduls nach Maßgabe 
des Renamingkonstrukts (falls vorhanden) durch andere ersetzt, und auf Module und Originfunk- 
tionen angewendet werden kann. Falls der Importbefehl für das Modul Mj/_ kein Renamingkon- 
strukt enthält, ist A' die Identität. 

k 

Unverändert bleiben in dieser Erweiterung (wie auch bei der hier nicht formalisierten Er- 
weiterung für Parameterbindungen) die Modulnamen im Wertebereich der Originfunktionen. So 
ist es zwar einerseits möglich, vorhandene Module zu modifizieren, andererseits können diese 
verschiedenen Aktualisierungen dann nicht unterschieden werden, was bei Mehrfachimporten zu 
ungewünschter Vermischung der Strukturen führt. 

ASF"*" geht hier einen anderen Weg. Die Modulnamen im Wertebereich der Originfunktion 
werden als Namensraumbezeichnungen interpretiert. Manipulationen wie explizites Renaming 
oder das Binden von Parametern stellen einen schwerwiegenden Eingriff in die den beteiligten 
Namen zugeordneten Namensräume dar. Um sicher zu stellen, daß Namen aus den veränderten 
Namensräumen nicht mit Namen des ursprünglichen Namensraumes identifiziert werden, ordenet 
ASF+ den veränderten Namensräumen neue Bezeichnungen zu. Diese setzen sich aus den alten 
Bezeichnungen und den Instanzbezeichnungen der instanziierenden Importbefehle zusammen. 
Wir sagen: Die Namensräume werden instanziiert. 

Ein interessanter Fall tritt ein, wenn durch Renaming oder Parameterbindung ein Modul 
verändert wird, das selbst weitere Module importiert, dessen (Signatur-) Namen also verschie- 
denen Namensräumen angehören. Ein undifferenziertes Instanziieren aller Namensräume würde 
zu zahlreichen überflüssigen Namenskonflikten führen. Beispielsweise beeinflußt das Binden des 
Parametertupels von OrdSequences (siehe Seite 7) beim Import das indirekt importierte Mo- 
dul Booleansin keinster Weise, so daß der Identifikation der Sorte BOOL mit dem Orginal (wel- 
ches möglicherweise mittels weiterer Befehle importiert wird) nichts entgegen steht. Andererseits 
können Manipulationen, die beim kopierenden Import vorgenommen werden auch indirekt im- 
portierte Teilsignaturen betreffen. In diesem Fall genügt es nicht, nur die Namensräume der direkt 
betroffenen Signaturnamen zu instanziieren. Vielmehr müssen ebenfalls alle Namensräume, die 
von den instanziierten Namensräumen abhängen bis hin zum Namensraum des direkt importier- 
ten Moduls instanziiert werden. 

Allgemein führt das Manipulieren von indirekt importierten Modulsignaturen zur Instanziie- 
rung mehrerer Namensräume. Zur Illustration betrachten wir ein ASF+-Beispiel: 
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module exA 
{ 

add signature{ public: sorts A } 



module exAB 
{ 

Import exA { public: A } 

add signature{ public: sorts B } 



module exABC 
{ 

Import exAB { public: A, B } 
add signature{ public: sorts C 

} 



module CopyDemo 
{ 

Import exABC[Copy]{ public: A, 

B renamed tc 
C } 

Import exABC { public: A } 

Import exABC { public: C } 

} 



CopyDemo 

exABC LCopy J 



exAB [CopyJ 




exA 

A 






Bnew 






C 







ex ABC 






ex AB 






exA 

A 






B 






C 







ex ABC 






ex AB 






exA 

: new, 

A 






B 






C 







Der erste Importbefehl von CopyDemo manipuliert die Signatur des (indirekt) importierten 
Moduls exAB. Dies führt zu einer Instanziierung des zugeordneten Namensraumes — Bnew 
gehört nun dem neuen Namensraum exAB [ Copy ] an. Auf die Signatur des ebenfalls (indirekt) 
importieren Moduls exA hat das keinen Einfluß, daher können die Sorten A aus den ersten bei- 
den Importbefehlen identifiziert werden und nach wie vor dem Namensraum exA angehören. 
Eine Manipulation in der Signatur von ex AB hat Einfluß auf die Signatur des ex AB importieren- 
den Moduls exABC, weil hier die veränderten Namen sichtbar sind und im allgemeinen auch in 
den Funktionsdeklarationen auftreten werden. ASP"*" ordnet dem Sortennamen C im ersten Im- 
portbefehl den instanziierten Namensraum exABC [ Copy ] zu. Im dritten Importbefehl gehört C 
dagegen dem (nicht modifizierten) Namensraum exABC an. Die Identifikationsregel sieht darin 
einen Namenskonflikt und wird die vorliegende Spezifikation nicht akzeptieren. ASF hingegen 
würde die beiden Sorten C identifizieren, was im allgemeinen die weiter oben bereits aufgezeigten 
Probleme bereitet. 

In ASF+ bleibt der Namenskonflikt auch dann bestehen, wenn der erste Importbefehl durch 

Import exABC[Copy] { public: A, B renamed to B, C } 

ersetzt wird. Der Ausdruck namei renamed to name2 hat im Kontext eines ASF+-Imports 
also zwei verschiedene Auswirkungen. Neben der Zugriffsänderung bewirkt er auch eine Instan- 
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ziierung eines oder mehrerer Namensräume. Ist man nur an letzterer Wirkung interessiert, kann 
ein Ausdruck name renamed to name sinnvoll sein, was in ASF+ auch als copy of name 
geschrieben werden kann. 

In beiden Fällen löst sich der Namenskonflikt auf, wenn der dritte Importbefehl in CopyDemo 
entfernt wird. 

Die Realisation der hier vorgestellten Semantik erfordert zwei Änderungen in der modifizier- 
ten Vereinigungssemantik. Zunächst muß der Wertebereich der Originfunktionen auf Namens- 
raumbezeichnungen ausgedehnt werden. Sie setzen sich aus Modulnamen und Instanzbezeich- 
nungen zusammen. Die Originfunktion des normalisierten Moduls ex ABC kann beispielsweise 
folgendermaßen dargestellt werden: {(A,exA), (B,exAB), (C,exABC)}. Neben der Umbenen- 
nung von B zu Bnew verändert das explizite Renaming auch den Wertebereich der Originfunk- 
tion: {(A,exA), (Bnew,exAB [Copy] ), (C,exABC [Copy] )}. Um ermitteln zu können, welche 
Namensräume instanziiert werden müssen, wird außerdem Information über den hierarchischen 
Aufbau der Spezifikation benötigt. Aus diesem Grund führen wir zur Erklärung der Semantik von 
ASP"*" eine zusätzliche Funktion namens Dependenzfunktion ein, die jedem innerhalb eines Mo- 
duls auftretenden Namensraum die Menge aller Namensräume zuordnet, die von ihm abhängen. 
Sie wird im folgenden Abschnitt 4.3 diskutiert. 

Die hier vorgestellte Sorte von Importen bezeichnen wir als kopierende Importe. Ihre Ver- 
wendung ist immer dann sinnvoll, wenn "wesentliche" Eigenschaften der importierten Struktur 
geändert werden sollen. Was aber sind "wesentliche" Eigenschaften? Neben den bereits disku- 
tierten Signaturmanipulationen (explizites Renaming und Parameterbindung) können im impor- 
tierenden Modul auch neue Konstruktoren und Funktionen zu einer importierten Sorte bereitge- 
stellt und im Gleichungsblock neue Beziehungen zwischen Elementen der importierten Struktur 
definiert werden (z. B. zwecks Erweiterung partiell definierter Funktionen). All dies hat Einfluß 
auf die Gültigkeit von Klauseln. Würde man in allen Fällen kopierenden Import verlangen, hätte 
das zur Folge, daß bewiesene Beweisziele eines Moduls beim benutzenden Import des Moduls in 
ein anderes ihre Gültigkeit behalten würden — ein denkbar einfacher Beweismodularisierungsan- 
satz. Formal erscheint diese "seiteneffektfreie" Semantik des benutzenden Imports optimal. Auch 
kann die Einhaltung der Restriktionen vom Normalformalgorithmus syntaktisch geprüft werden. 
Andererseits scheinen die Bedingungen für praktischen Gebrauch zu restriktiv, weil unnötig vie- 
le Namen und Instanzbezeichnungen den Blick auf das Wesentliche versperren. ASF+ schreibt 
den kopierenden Import nur bei Manipulationen durch Renaming und Parameterbindung vor und 
überläßt in allen anderen Fällen dem Spezifizierer die Wahl des Importtyps. 

Die folgende Spezifikation einer zyklischen Gruppe mit drei Elementen Nat3 kann als An- 
schauungsbeispiel dafür dienen, wie der kopierende Import auch über Renaming und Parameter- 
bindung hinaus als Spezifikationshilfsmittel sinnvoll eingesetzt werden kann: 
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module Nat3 
{ 

import Naturais [Nat 3 ] 
{ public: copy of NAT, 
0, s, + } 



variables { x: -> NAT } 
equations { [el] s(s(s(x))) = x 



Die Gleichung e 1 nimmt destruktiven Einfluß auf die importierte Datenstruktur. Würden hier 
die Namen NAT und s mit den Originalen aus Natural s identifiziert, so stände das unverfälsch- 
te Original für die gesamte Spezifikation nicht mehr zur Verfügung. Mit Einführung zusätzlicher 

Restriktionen (z. B. "Verbot des Auftretens von Termen aus ausschließlich benutzend impor- 
tierten Funktionssymbolen als linke Seite einer Gleichung im equations-Block.") könnte der 
kopierende Import von Naturais erzwungen werden. 



4.3 Abhängigkeiten zwischen Namensräumen 

Die hierarchische Struktur der Spezifikation bedingt Abhängigkeiten zwischen den erzeugten Na- 
mensräumen. Die Semantik von ASF+ wird ihnen durch Einführung einer sogenannten Depen- 
denzfunktion gerecht, welche der Bezeichnung jedes Namensraumes die Menge der Bezeichnun- 
gen aller von ihm abhängigen Namensräume zuweist. Diese Dependenzfunktion soll hier disku- 
tiert werden. 

Ein importfreies Modul M namens modn enthält nur einen Namensraum, nämlich den modu- 
leigenen. Seine Bezeichnung stimmt mit dem Modulnamen überein, Abhängigkeiten zu anderen 
Namensräumen bestehen nicht. Die zugehörige Dependenzfunktion lautet also 

depf :— {{modn,0)}. 

Der moduleigene Namensraum eines nicht importfreien Moduls M namens modn ist von 
allen importierten Namensräumen abhängig. Die zugehörige Dependenzfunktion depf kann aus 
den Dependenzfunktionen, die sich aus den einzelnen Importbefehlen ergeben, berechnet werden. 
Zu diesem Zweck definieren wir eine Hilfsfunktion CombineDependencies, die eine Menge von 
Dependenzfunktionen zu einer Funktion zusammenfaßt. 

CombineDependencies{{depf i \ i e ^4}) := 

{ {modinst, [J depf ^{modinst)) \ modinst e |^ Dorr\{depf i) A 

B = {i e A \ modinst e Dovn{depfi)} } 

Mit Hilfe von CombineDependencies kann nun die Dependenzfunktion depf für beliebige, 
nicht notwendigerweise importfreie Module definiert werden: 

depf := { {modn, 0) } U 

{ {modinst, modinstances U {modn}) \ {modinst, modinstances) 
e CombineDependencies{{depf-imp-const^ \ 1 < i < l}) } 
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wobei depf-imp-const- die zum i-ten Importbefehl des Moduls M zugehörige Dependenzfunk- 
tion beinhaltet (1 < i < 0- Wie die zu einem Importbefehl zugehörige Dependenzfunktion 

depf-imp-const aus der Dependenzfunktion depf-imp-mod des importierten Moduls zu berechnen 
ist hängt vom Importtyp ab und wird im folgenden erklärt. 

Handelt es sich um einen benutzenden Import des Moduls M-imp und ist depf-imp-mod die 
Dependenzfunktion des Moduls, so gilt depf-imp-const := depf-imp-mod. 

Handelt es sich dagegen um einen kopierenden Import von M-imp, in dem explizites Rena- 
ming durchgeführt wird, dann geht depf-imp-const aus depf-imp-mod dadurch hervor, daß jedes 
Auftreten von Bezeichnungen der vom Renaming direkt betroffenen Namensräume sowie der von 
diesen bezüglich depf-imp-mod abhängigen Namensräume durch die mit der Instanzbezeichnung 
des Importbefehls instanziierten Namensraumbezeichnung ersetzt wird. 

Werden formale Parameter an Namen aus k aktuellen Modulen M-actj (1 < j < k) gebunden, 
so sind zusätzlich die Namensraumbezeichnungen aller formalen Parameter, an die aktuelle Para- 
meter gebunden werden, sowie alle bezüglich depf-imp-mod von ihnen abhängigen Namensräume 
in depf-imp-mod zu instanziieren. Die resultierende Funktion nennen wir depf-imp-mod'. Des 
weiteren sind die Namensraumabhängigkeiten der implizit importierten aktuellen Module depf-act-modj 
zu berücksichtigen. Sei analog zum expliziten Import 

depf-imp-const :— CombineDependencies{{depf-imp-mod'} U 

{depf-act-mod'j | 1 < j < k}). 

Würde man hier depf-act-mod'j mit depf-act-modj gleichsetzen, so entsprächen die aus implizitem 
Import resultierenden Abhängigkeiten innerhalb des bindenden Moduls denen eines benutzenden 
Imports. Unberücksichtigt blieben dabei jedoch die Beziehungen zwischen dem Modul der for- 
malen Parameter (hier M-imp) und den Modulen der aktuellen Parameter (hier M-actj). Dies ist 
jedoch erforderlich: Werden beispielsweise bei einem späteren Import des bindenden Moduls 
(hier M) aktuelle Parameter aus der Bindung umbenannt, so hat dies auch Einfluß auf die Namen 
des Moduls der formalen Parameter. Allgemein definieren wir daher: 

depf-act-mod'j :— { {modinst, modinstances U {paradef modinst j} U 

depf-imp-mod' {paradef modinst ^ ) | 
{modinst, modinstances) e depf-act-modj }, 

wobei paradef modinst, j der Namensraum der an Namen des Moduls M-actj zu bindenden forma- 
len Parameter des Moduls M-imp ist. 

Im folgenden Beispiel werden die Abhängigkeiten zwischen den Namensräumen aus OrdNat Sequ? 
durch die zugehörige Dependenzfunktion dargestellt. Sie kann auch aus dem in Kapitel 3 vorge- 
stellten Strukturdiagramm gewonnen werden. 

{ (Booleans, { Naturais, OrdNaturals, OrdSequences[ONSeq] , OrdNatSequences }), 
(Naturais, { OrdNaturals, OrdSequences[ONSeq] , OrdNatSequences }), 
(OrdSequences[ONSeq] , { OrdNatSequences }) } 
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4.4 Verdeckte Namen 

Im Prinzip könnten alle Namenskonflikte, die beim Import von Modulen auftreten, durch "expli- 
zite" Umbenennungen (s. o.) aufgelöst werden. Allerdings erfordert dies vom Spezifizierer einen 
Überblick über alle eingeführten Namen, was mit zunehmender Spezifikationskomplexität immer 
schwieriger wird. Um den Spezifizierer vom Umbenennen "unwichtiger" Namen zu entlasten, 
unterscheidet ASF sichtbare und verdeckte Namen. Während die Konfliktlösung zwischen sicht- 
baren Namen weiterhin in der Verantwortung des Spezifizierers liegt, werden Konflikte zwischen 
verdeckten Namen vom Normalformalgorithmus durch automatisches Umbenennen (implizites 
Renaming) aufgelöst. 

ASF beschränkt die Referenzierbarkeit verdeckter Namen jeweils auf das definierende Mo- 
dul, was für Variablen (sie können in diesem Sinne als verdeckt betrachtet werden) ausreichend 
ist. Um die Zahl der Konflikte zwischen Sorten- und Funktionsnamen wirksam zu reduzieren, 
erscheint diese Einschränkung jedoch zu restriktiv. Wünschenswert wäre ein Mechanismus, der 
es erlaubt, Namen, die in der jeweiligen Spezifikationsebene nicht mehr gebraucht werden, "aus- 
zublenden". Modulare Programmiersprachen stellen zu diesem Zweck Ex- und Importlisten zur 
Verfügung. 

ASF+ übernimmt die Importlisten (alle weiterhin sichtbaren Namen müssen im Importkon- 
strukt aufgeführt werden). Das Exportverhalten von Namen wird dagegen direkt in der Definition 

bzw. beim Import durch die Schlüsselworte private und public festgelegt. Dies reduziert 
den Code und dient der Übersicht. Werden Namen beim Import verdeckt, so ersetzt der Normal- 
formalgorithmus alle diese Namen durch neue, innerhalb der gesamten Spezifikation eindeutige 
Namen. Zu diesem Zweck wird dem alten vom Spezifizierer vereinbarten Namen der (abgekürz- 
te) Name des entsprechenden Namensraumes gefolgt von einem Bindestrich vorangestellt. Bei- 
spielsweise werden die Namen and, or und not aus Booleans beim verdeckten Import in das 
Modul Naturais durch Bo-and, Bo-or und Bo-not ersetzt. Neben der Trennungsfunktion 
zwischen Namensraum und ursprünglichem Namen garantiert der Bindestrich die Konfliktfreiheit 
zwischen verdeckten und sichtbaren Namen, da er in letztgenannten nicht zugelassen ist. 

Besonders nützlich erweist sich das Instrument der Namensverdeckung in Verbindung mit 
dem kopierenden Import, bei dem zahlreiche Namensumbenennungen erforderlich werden, da 
Signatumamen aus verschiedenen Instanzen eines Moduls nicht miteinander identifiziert werden 
dürfen. ASF"*" erledigt das für die verdeckten Namen automatisch, der Spezifizierer muß sich 
lediglich um die sichtbaren, ihn interessierenden Namen kümmern. 

4.5 Overloading 

Bisher gingen wir davon aus, daß jeder Signatumame genau ein Signaturobjekt (Sorte oder Funk- 
tion) spezifiziert. In der Praxis ist es jedoch sehr nützlich, wenn verschiedene Objekte mit dem 
gleichen Namen referenziert werden können. Beispielsweise schreibt man gewöhnlich die Sum- 
me zweier Zahlen x und y als {x + y), egal, ob es sich bei x und y um natürliche, ganze oder 
rationale Zahlen handelt. Die tatsächliche Bedeutung des Namens "-I-" ergibt sich aus dem Kon- 
text. 

Das aus ASF übernommene Overloading gestattet es, Funktionsnamen zu überladen, wenn 
diese sich in ihren Argumentsorten unterscheiden. Die Restriktion erlaubt es, durch Bottom- Up- 
Sortenprüfung jedem Funktionsnamen innerhalb eines Terms eine eindeutige Funktion zuzuord- 
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nen. Um überladene Funktionen behandeln zu können, müssen wir im Definitionsbereich der Ori- 
ginfunktion zu disambiguierten Namen übergehen. Dabei handelt es sich um Tupel (specname, 
sortvector) bestehend aus dem Signatumamen und einem (für n-stellige Funktionen n-dimensionalen) 
Sortenvektor. Jede Funktionsdeklaration im add signature-Konstrukt definiert genau einen 
neuen disambiguierten Namen. Der Import eines Funktionsnamens zieht im allgemeinen den Im- 
port mehrerer disambiguierter Namen nach sich. Ist als Ergebnis der Normalisierung eine über- 
ladungsfreie Spezifikation gewünscht, kann dies erreicht werden, indem alle Funktionsnamen 
des Normalformmoduls durch eine geeignete Repräsentation ihrer disambiguierten Namen (z. B. 
+ [ NAT , NAT ] ) ersetzt werden. 
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5 Syntax 



Die Syntax von ASF+ ist gegeben durch folgende kontextfreie Grammatik^: 

<specification> ::= <module>+ 

<module> ::= "moduie" <module-name>[ "<" <parameter-block>+ ">" ] 
[ "Short" <short-module-name> ] 
"{" <import>* 

[ <add-signature> ] 
[ <variables> ] 
[ <equations> ] 
[ <goals> ] "}" 
<parameter-block> ::= " (" (<sort-or-func-name> ", ")+ ") " 
<sort-or-func-name> ::= <sort-name> | <function-name> 

<import> ::= "Import" <module-name>[ " ["<instance-name>"] " ] 
[ "<" <ext-para-block>+">" ] 
[ <import-block> ] 
<ext-para-block> ::= " ("(<name-with-ren> ", ")+ ") " 

I " ("(<sort-or-func-name> "bound to" <sort-or-func-name> ",")'*' 
") " "of" <module-name>[ "<" <parameter-block>+ ">" ] 
<name-with-ren> ::= <sort-or-func-name> [ "renamed to" <sort-or-func-name> ] 

I "copy of" <sort-or-func-name> 
<import-block> ::= "{" ["public:" (<name-with-ren> ", ")^ ] 

[ "private : " «name-with-ren> ", ")+ ] "}" 
<add-signature> ::= "add signature" 

"{" ["Parameters:" <para-blOCk-sig>+ ] 

["public:" <signature> ] 
["private:" <signature> ] "}" 
<para-block-sig> ::= "(" <signature> 

[ "conditions" <clause>+ ] ")" 

<signature> ::= [ "sorts" (<sort-name> ",")"^ ] 

[ "constructors" <function-dec>+ ] 

[ "non-constructors" <function-dec>+ ] 

<function-dec> ::= (<ext-func-name> ",")^ ":" (<sort-name> "#")* 

"->" <sort-name> 
<ext-func-name> ::= <function-name> [ "_" ] 

I "_" <function-name> "_" 

<clause> ::= "["<label>"]"(<eq>",")*"— >"(<eq>",")* 
<eq> ::= <term> [ "=" <term> ] 



Wir kennzeichenen Terminale durch Anführungszeichen und Typewriterfont und Nichtterminale durch spitze 
Klammern (< . . .>). x* bedeutet null, eine oder mehrere und x'^ eine oder mehrere Wiederholungen von x, (x "ts")* 
und (x "ts")~^ stehen für Wiederholungen von x, getrennt durch das Terminalsymbol ts. Optionale Zeichenketten 
sind in eckige Klanmiern ([. . .]) eingefaßt. 
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<term> ::= [ <term> <function-name> ] <primary> 
<primary> ::= <function-name>[ " (" (<term> ", ")+ ") " ] 
I <variable-name> 
I "("<term>")" 
I <function-name> <primary> 
<variables> ::= "variables" 

"{" [ [ "constructors"] <variable-dec>+ ] 

[ "non-constructors" <variable-dec>+ ] "}" 
<variable-dec> ::= (<variable-name> ",")^ ".""_>" <sort-name> 
<equations> ::= "equations" 

"{" <equation>+ "}" 
<equation> ::= " [" <label>"] " <eq> [ "if " (<eq> ", ")+ ] 
I <macro-equation> 
<goals> ::= "goals" 

"{" <clause>+ "}" 



Lexikalisch gelten in der Syntax von ASF"*" folgende Konventionen: 

• Als Trennzeichen zwischen den einzelnen lexikalischen Token sind erlaubt: Leerzeichen, 
horizontaler Tabulator, carriage retum, Zeilen- und Seitenvorschub sowie jede Kombination 
dieser Zeichen. 

• Modulnamen, -kürzel, Instanzbezeichnungen, Marken- und Sortennamen (also <module- 
name>, <short-module-name>, <instance-name>, <label> und <sort-name>) be- 
stehen aus einer beliebigen Folge von Zahlen, Buchstaben, Apostroph ") und Unterstrich 
("_")• Jedoch darf der Unterstrich weder am Anfang, noch am Ende eines Namens stehen. 

• In Funktonsnamen (<f unction-name>), die hier auch die Operatoren aus ASF beinhalten, 
sind zusätzlich folgende ASCI-Zeichen zulässig: "!", "$", "%", "&", "+", "?", 

(6 99 tt\ 99 4t|99 / 99 99 

9 \ 9 I 9 / 9 • • 

• Die Schlüsselworte "if ", "equat ion", "eise", "case", "renamed", "bound", "sort s" 
und "constructors" stehen als Namen nicht zur Verfügung. 

Man beachte, daß in benutzerdefinierten Modulen Sorten-, Funktions- und Markennamen kei- 
nen Bindestrich ("-") enthalten dürfen. Andernfalls wären Namenskonflikte zwischen benutzer- 
definierten und verdeckten, vom Normalformalgorithmus erzeugten Namen nicht auszuschließen. 



30 



6 Die Normalform-Prozedur 

Im Mittelpunkt dieses Kapitels steht der Algorithmus, mit dessen Hilfe beliebige ASF"*"- Spezifikationen, 
bestehend aus einem Topmodul und einer Folge von direkt, indirekt und implizit importierten 
Modulen, in flache, importfreie Spezifikationen umgewandelt werden können. Besonderen Wert 
wurde auf die möglichst konsequente Verwendung disambiguierter Namen gelegt. Die Forma- 
lisierung des ASF zugrunde liegenden Algorithmus in [Bergstra&al.89], Kapitel 1.3.2, läßt hier 
einige Fragen offen^. Schwerwiegender ist dagegen das (nicht dokomentierte) Fehl verhalten des 
ASF-Normalformalgorithmus bei mehrfachem Import namensgleicher Sorten und Funktionen 
mit unterschiedlicher Sichtbarkeit: 

module exhiddenA 
begin 

sorts A 
end exhiddenA 

module exA 
begin 

exports begin sorts A end 
end exA 

module Certain-Clash 
begin 

Imports exhiddenA, exA 
end Certain-Clash 

Daß die Normalisierung von ASF hier einen Namenskonflikt ausgibt, erscheint genauso un- 
verständlich wie die Tatsache, daß er sich durch Änderung der Importreihenfolge in Certain-Clash 
beheben läßt. Zwar wird in der Beschreibung der Hilfsfunktion combine^ daraufhingewiesen, daß 
verdeckte Namen des ersten Arguments mit sichtbaren Namen des zweiten Arguments kollidie- 
ren können, ein Hinweis auf die kaum akzeptablen Auswirkungen auf die Kombination mehrerer 
zu importierender Module (im Beispiel exhiddenA und exA) fehlt jedoch völlig. 

Der gleiche Fehler führt zusammen mit dem nur unpräzise formalisierten impliziten Rena- 
ming sogar dazu, daß Namenskonflikte zwischen Namen, die durch die Normalisierung überhaupt 
erst erzeugt wurden, nicht auszuschließen sind: 

module exAhiddenA 
begin 

exports begin sorts A end 
Imports exhiddenA 
end exAhiddenA 



^Beispielsweise ist der zweite Wert eines RENAMING-Tupels {x,y) im allgemeinen kein Element aus SFV. 
Trotzdem wird ihm in der Beschreibung von renamc-visibles ein Origin zugeordnet. 
^Siehe [Bergstra&al.89], Absatz 1.3.2.2.3 
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module exB 
begin 

sorts B 
end exB 

module Possible-Clash 
begin 

Imports exAhiddenA, exB 
end Possible-Clash 

Im Zuge der Normalisierung wird zunächst exAhiddenA in Normalform gebracht. Die 
dabei notwendige Umbenennung der verdeckt importierten Sorte A erledigt die Funktion rena- 
meJiiddens. Da sie keine Kenntnis über das Modul exB hat, steht einer Ersetzung des Namens A 
durch B aus Sicht des Algorithmus nichts im Wege. In diesem Fall aber liefert die Normalisierung 
von Possible-Clash wieder einen Namenskonflikt (gleiche Situation wie oben). 

Grund für die Namenskonflikte beider Beispiele ist die Asymetrie der Hilfsfunktion combine, 
die beim kombinieren zweier Module zwecks Konfliktvermeidung nur Umbenennungen inner- 
halb eines Modules vornehmen darf und sowohl bei der Kombination von Importen untereinan- 
der, als auch mit dem importierenden Modul selbst Verwendung findet."* Wir ersetzten combine 
durch zwei verschiedene Varianten: Combineimports kombiniert zwei importierte Module unter- 
einander. Ihre Argumente (zwei Module in Normalform) werden gleich behandelt, somit ist die 
Reihenfolge der Importanweisungen belanglos. CombineWithlmports entspricht in etwa combine 
aus ASF — sie kombiniert das importierende Modul mit der Kombination aller Importe. 

6.1 Datenstrukturen 

Bevor der Normalformalgorithmus vorgestellt werden kann, müssen zunächst die Daten erläutert 
werden, auf denen er operiert. Als Basistyp beschränken wir uns auf Zeichenketten. Sie werden in 
Mengen- und Strukturtypen, die wir als Tupel mit unterschiedlichen Komponententypen darstel- 
len werden, zu komplexeren Datenstrukturen zusammen gesetzt. Funktionen werden als Mengen 
repräsentiert: / = {{x,y) \ y = f{x)}. ViX) bezeichnet die Potenzmenge von X, also die 
Menge aller Teilmengen. 

Ziel der Normalisierung ist die Transformation einer ASF^-Spezifikation, bestehend aus ein- 
zelnen ASF+-Modulen, in eine neue importfreie ASF+-Spezifikation. Neben den Typen ASF-MODULE 
und ASF-SPEC werden für die Eingabeschnittstelle der Normalisierungsprozedur auch Informa- 
tionen über bereits geführte Beweise benötigt. Sie werden im Typ PROVE-DB zusammengefaßt. 

• ASF-MODULE ist die Menge aller Zeichenfolgen, die syntaktisch korrekte ASF^-Module 
darstellen. 

• ASF-SPEC := ASF-MODULE x P(ASF-MODULE) 

ASF+-Spezifikationen bestehen aus einem Topmodul und einer Menge von Modulen, die 
mindestens alle vom Topmodul direkt, indirekt und implizit importierten Module enthalten 
muß. 



'^Siehe [Bergstra&al.89], Absatz 1.3.2.3, 4. Schritt des Algorithmus 
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• PROVE-DB ist eine nicht näher konkretisierte Wissensbasis für gelungene Beweise. Mit 
ihrer Hilfe wird die Gültigkeit von semantischen Bedingungen für Parameterbindungen 
geprüft. 

Allerdings eignet sich die Repräsentation eines ASF+ -Moduls als unstrukturierte Zeichenket- 
te kaum zur adäquaten Beschreibung der für die Transformation notwendigen Operationen (z. B. 
Kombination mehrerer Module). Wir führen daher einen strukturierten Datentyp MODULE ein, 
der es ermöglicht, auf einzelne Teile eines repräsentierten Moduls (z. B. auf die Importbefeh- 
le) direkt zuzugreifen. Die kleinsten logischen Einheiten eines Moduls bestehen aus Namen, die 
in Abhängigkeit vom Kontext ihres Auftretens als Modulnamen oder -kürzel, als Marken, In- 
stanzbezeichnungen, Variablen-, Sorten- oder als Funktionsnamen dienen. Unter den Sorten- und 
Funktionsnamen besitzen wiederum in einer Parametersignatur definierten Namen einen Sonder- 
status, sie heißen Sorten- und Funktionsparameter. Einige Namen werden während der Norma- 
lisierung verändert oder zur Veränderung anderer Namen gebraucht. Um die Zahl der Namens- 
typen möglichst überschaubar zu halten, fassen wir Namen, auf denen die gleichen Operationen 
ausgeführt werden, gruppenweise zusammen: 

• MODULE-NAME ist Menge aller Modulnamen. 

• SHORT-MODULE-NAME ist Menge aller abgekürzten Modulnamen. Sie enthält alle Mo- 
dulkürzel sowie die Namen der Module, für die kein Kürzel angegeben worden ist. Unter 
dem "abgekürzten Namen eines Moduls" verstehen wir das im Modul vereinbarte Kürzel, 
oder (falls nicht vorhanden) den Modulnamen selbst. 

• INST-NAME ist Menge aller Instanzbezeichnungen. 

• USER-NAME ist die Menge aller dem Spezifizierer zur Verfügung stehenden Namen für 
Parameter, Sorten, Funktionen, Variablen und Marken. 

Neben den vom Spezifizierer erzeugten Namen generiert der Normalformalgorithmus auch 
selbstständig Namen, die sich (im Gegensatz zu ASF) aus den vom Spezifizierer vorgegebenen 
Namen und Kürzeln zusammensetzen. Das modulare Konzept aus ASF+ basiert wesentlich auf 
der Zuordnung von Namen zu Namensräumen. Eine Namensraumbezeichnung besteht aus einem 
Modulnamen und einer gegebenenfalls leeren Liste von Instanzbezeichnungen, welche Auskunft 
darüber gibt, um welche Version des Namensraumes es sich handelt. Auch Namensraumbezeich- 
nungen können mit Hilfe der Modulkürzel abgekürzt werden. 

• MOD INST-NAME enthält alle Namensraumbezeichnungen. Syntaktisch kann MODINST-NAME 
durch eine Grammatik-Produktionsregel wie folgt beschrieben werden: 



MODINST-NAME ::= MODULE-NAME 

I MODULE-NAME" ["(INST-NAME ", ")+"] " 
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• SHORT-MODINST-NAME enthält alle abgekürzten Namensraumbezeichnungen. 

SHORT-MODINST-NAME ::= SHORT-MODULE-NAME 

I SHORT-MODULE-NAME" ["(INST-NAME ")+"] " 

Wird beim Import ein Name verdeckt, so ersetzt der ASF^-Normalforalgorithmus den Namen 
durch einen neuen, innerhalb der gesamten Spezifikation eindeutigen Namen, indem er dem alten 
Namen eine abgekürzte Namensraumbezeichnung gefolgt von einem Bindestrich voranstellt. Der 
so erzeugte Name ist kein USER-NAME, kann also mit keinem vom Spezifizierer eingeführten 
Namen in Konflikt geraten. 

• SPEC-NAME umfaßt alle Parameter-, Sorten-, Funktions-, Variablen- und Markennamen, 
die nach der Normalisierung in der Spezifikation auftreten können. Zur Charakterisierung 
der Syntax geben wir wieder eine Produktionsregel an: 

SPEC-NAME ::= USER-NAME | SHORT-MODINST-NAME"-"USER-NAME 

ASF+ gestattet es, Funktionsnamen zu überladen. Um eine spezielle Funktion identifizieren 
zu können ist deshalb die Kenntnis der Argumentsorten erforderlich. Dies führt uns zu disambi- 
guierten Namen: 

• SORT-VECTOR ist eine Menge von Listen, deren Komponenten Sortennamen (e SPEC-NAM E) 
sind. 

• DISAMB-SPEC-NAME := SPEC-NAME x SORT-VECTOR 

umfaßt die Menge der disamiguierten Namen. Disambiguierte Namen sind Tupel (name, 
sortv). Falls name ein Sorten-, Marken-, Variablen oder Konstantenname ist, ist der Sorten- 
vektor sortv leer. Handelt es sich dagegen um einen Funktionsnamen (bzw. Funktionspara- 
meter) enthält er die Namen der Argumentsorten. 

Die Datenstruktur für die Importe nimmt alle, aus den Importkonstrukten hervorgehenden 
Informationen auf, gruppiert sie nach den Erfordernissen der sequenziellen Auswertung jedoch 
neu: 

• VISIBILITY-FUNC := USER-NAME — ^ {"public", "private"} 

Sie bestimmt die Sichtbarkeit von Signatumamen beim Import eines Moduls. Da ASF+ ver- 
langt, daß alle nach dem Import sichtbaren Namen im Importkonstrukt aufgeführt werden 
müssen, kann sie direkt aus der Importanweisung bestimmt werden. Namen aus dem impor- 
tierten Modul, die keine Parameter sind und denen keine Sichtbarkeitsstufe e {"public", 
"private"} zugewiesen wird, werden beim Import verdeckt. 

• RENAMING-FUNC := USER-NAME — > SPEC-NAME 

Werden Sorten- und Funktionsnamen durch eine Funktion aus RENAMING-FUNC auf 
andere Sorten- und Funktionsnamen abgebildet, so beschreibt diese Funktion explizites 
Renaming. Handelt es sich dagegen im Definitionsbereich ausschließlich um Parameter, so 
kann mit ihrer Hilfe eine Parametertupelbindung beschrieben werden: 

• BINDING-BLOCK := RENAMING-FUNC X MODULE-NAME 

Tupel {binding, modn) dieses Typs repräsentieren einen Block des Importbefehls, der über 
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binding das Binden von Parametern eines Tupels an Signatumamen eines Moduls namens 
modn beschreibt. 

• IMPORT MODULE-NAME x INST-NAME x VISIBILITY-FUNC x RENAMING-FUNC 
X T'CBINDING-BLOCK) 

Elemente dieses Typs repräsentieren Importbefehle. Es handelt sich hier also um eine struk- 
turierte Repräsentation einer Zeichenkette, die den Import in ASF+ beschreibt. Wird ein 
benutzender Import dargestellt, ist die zweite Komponente leer. 

Zur Veranschaulichung sei als Beispiel folgender Importbefehl gegeben: 

Import Sequences [NSeq] <(ITEMpar bound to NAT) of Naturals> 
{ public: SEQ renamed to NSEQ 

private: nil renamed to nnil, cons } 

Wir erhalten folgende Tupeldarstellung: 

( "Sequences", "NSeq", 
{("SEQ", "public"), ("nil", "private"), ("cons", "private")}, 
{("SEQ", "NSEQ"), ("nil", "nnil")}, 
{({("iTEMpar", "NAT")}, "Naturais")} ) 

Während Importkonstrukte nur Teil einer nicht normalisierten Spezifikation sind, ist das Auf- 
treten von Signaturen, Variablenvereinbarungen, Klauseln und Gleichungen unabhängig vom 
Grad der Normalisierung: 

• SIG :=P(SPEC-NAME) x P(DISAMB-SPEC-NAME x SPEC-NAME)^ 

Dieser Datentyp repräsentiert eine Teilsignatur eines Moduls. Teilsignaturen bestehen aus 
einer Menge von Sortennamen und je einer Mengen von Deklarationen für Konstrukto- 
ren und Non-Konstruktoren. Jede Deklaration wird durch einen disambiguierten Namen 
(Funktionsname + Argumentsorten) und die zugehörigen Zielsorte repräsentiert. 

• VAR-SORT-FUNC := SPEC-NAME — ^ SPEC-NAME 

Die Variablenvereinbarung eines Moduls beschreibt eine Funktion, die jedem Variablenna- 
men eine Sorte zuweist. 

• CLAUSE 

• EQUATION 

Mit Hilfe der so definierten Strukturen kann nun ein ASF+ -Modul wie folgt als 9-Tupel re- 
präsentiert werden: 

• MODULE := MODULE-NAME x P(IMPORT) x P(SIG x P(CLAUSE)) x SIG^ x 
VAR-SORT-FUNC^ x P(EQUATION) x P(CLAUSE) 

Dem Modulnamen folgen die Importe, eine Menge von Parametersignaturen (mit Bedin- 
gungsklauseln), die exportierte (public) und die nur innerhalb des Moduls sichtbare 
(private) Signatur, zwei Funktionen, die den Konstruktor- bzw. Non-Konstruktor- Variablen 
ihre jeweilige Sorte zuweisen, eine Menge von spezifizierenden Gleichungen und schließ- 
lich eine Menge von Beweiszielen. 
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Wir können nun präzisieren, was wir im Folgenden unter der komponentenweisen Vereini- 
gung einer Menge von Modulen verstehen werden: 

Sei {modulei \ i E A} eine Menge von Modulen und es gelte füri e A 

modulci = ( modinamei, importSi, parametersi, 

(sorts,,t,i, const^„i,_i,, non-const^,^^i), 
(sortSp,i^i, constp,,^i, non-const^,,^i), 
varsonfunc,„^,^i, varsortfunc^^. 

const,25 

equationsi, goalsi ). 

|_J modulei '■— 

( 0, [J Imports i, [J Parameters i, 
(IJ sortSp,i,^i, [j constp,h,i, [j non-constp,i„i) , 

ieA ieA ieA 

(IJ sorts^,,^i, U constj„i^i, (J non-const^^i) , 

ieA ieA ieA 

U ^(^rsortfunc^^^^^i, \J varsortfunc^„^_^^^^i, 

ieA ieA 

[J equationSi, [J goals^ ) 

ieA ieA 

Im Zuge der Importelemination geht Information über den hierachischen Aufbau der Spezi- 
fikation und die Herkunft der Signaturnamen verloren. Um dieses Wissen der Normalisierungs- 
prozedur zugänglich zu machen, werden eine Origin- und eine Dependenzfunktion eingeführt: 



• ORIGIN := USER-NAME x MODINST-NAME x {"label", "variable", "sort", 
"function"} x {"parameter", "public", "private", "hidden"} 
Im Prinzip würden Origins, die Auskunft über den Namensraum eines Bezeichners geben, 
ausreichen, um die angestrebte Semantik zu realisieren. Zur Formulierung des Normalfor- 
malgorithmus erweist es sich jedoch als zweckmäßig, weitere redundante Informationen, 
beispielsweise aus der Signatur aufzunehmen. In ASF+ werden Origins als Viertupel er- 
klärt. Die vier Komponenten eines Origins {uname, defmodiname, symboltype, visibility) 
sind wie folgt definiert: 

- uname enthält den Namen (G USER-NAME), der vom Spezifizierer für die spezifi- 
zierte Sorte, Funktion, Variable oder Marke (im folgenden als das spezifizierte Objekt 
bezeichnet) eingeführt wurde. Explizites Renaming verändert nicht nur den Namen 
selbst sondern auch den Eintrag uname des zugeordneten Origins. 

- modiname gibt Auskunft über den Namensraum, dem der Name angehört. 

- symboltype: Namensänderungen (sowohl implizites als auch explizites Renaming) 
werden im Normalformalgorithmus von ASF+ in zwei Stufen durchgeführt. Zunächst 
werden alle Sorten, Variablen und Marken umbenannt (für zugehörige Origins gilt 

symboltype G {"label", "variable", "sort"}, danach folgt die Umbenennung 
der Funktionen. Diese Reihenfolge operationalisiert die durch Overloading bedingte 
rekursive Struktur der Identifikationsregel aus ASF"*". 
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- visibility: Für Sorten und Funktionen gibt es drei Sichtbarkeitsstufen: 

* "public": innerhalb des Moduls sichtbar und exportfähig. 

* "private": innerhalb des Moduls sichtbar, jedoch nicht exportfähig. 

* "hidden": innerhalb des Moduls verdeckt und natürlich auch nicht exportfähig. 

Marken und Variablen gelten innerhalb des Moduls, in dem sie definiert werden als 
"private", beim Import des Moduls werden sie verdeckt. Parameter gehören dem 
Sonderstatus "parameter" an und können nicht verdeckt werden. 

• ORIGIN-FUNC := DISAMB-SPEC-NAME ORIGIN 

Funktionen dieses Typs weisen (disambiguierten) Namen aus der Spezifikation Origins zu. 

• DEPENDENCY-FUNC := MODINST-NAME — > P(MODINST-NAME) 
Dependenzfunktionen beschreiben die Abhängigkeiten zwischen Namensräumen einer Spe- 
zifikation. Jeder Namensraumbezeichnung aus dem Definitonsbereich wird die Menge der 
Bezeichnungen aller abhängigen Namensräume zugewiesen. 

Der rekursive Normalformalgorithmus operiert auf einer Datenstruktur, die wir "general forms" 
(GF) nennen: 

• GF := MODULE x ORIGIN-FUNC x DEPENDENCY-FUNC 

General forms bestehen aus der (internen) Repräsentation eines Moduls, einer Originfunk- 
tion und einer Dependenzfunktion. Origin- und Dependenzfunktion können partiell sein in 
dem Sinn, daß Namen aus zu importierenden Modulen zunächst unberücksichtigt bleiben. 

• NFCGF 

Als Normalformen bezeichenen wir alle general forms, die ein importfreies Modul, eine auf 
den im Modul vorkommenden Namen (G DISAMB-SPEC-NAME) totale Originfunktion 
und eine auf den Bezeichnungen aller im Modul enthaltenen Namensräume totale Depen- 
denzfunktion beinhalten. Eine Normalform repräsentiert also nicht nur ein normalisiertes 
Modul sondern auch den Bauplan der Spezifikation, der das Modul seine Erzeugung ver- 
dankt. 



Schließlich wird für die Normalisierungsprozedur noch eine Funktion benötigt, die Namen- 
sumbenennungen einzelner ggf. überladener Signaturnamen eindeutig beschreibt. Da sich das 
Exportverhalten überladener Funktionsnamen unterscheiden kann, ist eine Differenzierung nach 
den Argumentsorten erforderlich: 

• DISAMB-RENAMING-FUNC := DISAMB-SPEC-NAME SPEC-NAME 

Dieser Datentyp beschreibt Umbenennungen, die aufgrund von Änderungen der Sicht- 
barkeit einzelner Namen beim Import erforderlich werden. Es ist zu beachten, daß die 
Durchführung von Funktionsumbenennungen dieser Art in Gleichungen das Disambiguie- 
ren der Funktions Symbole jedes einzelnen Terms erfordert. Hierzu wird die Signatur des 
Moduls gebraucht. 
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6.2 Der Algorithmus 

6.2.1 Globale Hilfsfunktionen für Sichtbarkeitsänderungen 

Das dynamische Verdeckungsprinzip von ASF+ erfordert bei der Kombination verschiedener 
Module zahlreiche Signaturnamensumbenennungen. Jede Namensänderung zieht im allgemeinen 
Veränderungen in fast allen Teilen des Moduls und der Originfunktion nach sich. Der Normalfor- 
malgorithmus erledigt dies in zwei Schritten. Zuerst wird die 4. Komponente visibility der Origins 
aller Namen auf die Sichtbarkeitsstufe gesetzt, die die jeweiligen Namen zukünftig haben sollen. 
Die sich daraus ergebenden Umbenennungen im Modul und dem Definitionsbereich der Origin- 
funktion, sowie die Neuordnung der Signatur werden dann von der Funktion MakeConsistent 
erledigt. 

Die Vorgehensweise des hier vorgestellten Algorithmus nutzt die in der Originfunktion ent- 
haltene Redundanz aus: Jedes Origin origin beschreibt den ihm zugeordneten (nicht disambi- 
guierten) Namen GetSpecName(origin) eindeutig. 



GetSpecName: ORIGIN 

— > SPEC-NAME 



GetSpecName((uname, modiname, *, visibility)) berechnet aus der ersten, zweiten und 
vierten Komponente eines Origins den zugeordneten (nicht disambiguierten) Namen (e 
SPEC-NAME). 



falls visibility e {"parameter", "public", "private"} 
Setze specname '.= uname. 



falls visibility = "hidden" 

Setze shortmodiname gleich dem abgekürzten Modulinstanznamen von modina- 
me. 

specnam-e '.= shortmodiname" -"uname 



Rückgabewert: specname 
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Manipulationen der Sichtbarkeitskomponente im Wertebereich einer Originfunktion führen 
im allgemeinen dazu, daß die Namen des Definitionsbereichs nicht mehr zu den zugeordne- 
ten Origins passen. Sei ((namei, sortVi), origirii) Element einer Originfunktion, dann entspricht 
GetSpecName{origini) dem "Sollwert" von namei. Zur Namensaktualisierung im Modul und im 
Definitionsbereich der Originfunktion dient eine "Istwert-Sollwert" -Liste, die von GetRenaming 
erzeugt wird: 



GetRenaming: ORIGIN-FUNC x P({"label", "variable", "sort", "function"}) 
— > DISAMB-RENAMING-FUNC 



GetRenaming{originf , symboltypes) errechnet ein renaming für disambiguierte Namen. 
Mit dessen Hilfe kann innerhalb der Originfunktion sowie eines Normalformmoduls ein 
konsistenter Zustand hergestellt werden, symboltypes bestimmt, welche Namenstypen in 
das renaming aufgenommen werden sollen. 



renaming := { {{name, soriv), name') \ 

{u, n, symboltype, v) — originf{{name, soriv)) A 
symboltype G symboltypes A 
name' = GetSpecName{{u,n, symboltype, v)) A 
name' ^ name } 

Rückgabewert: renaming 



Bei der Beschreibung von Umbenennungen überladbarer Signaturnamen ist zu berücksichti- 
gen, daß Sortenumbenennungen auch die Sortenvektoren der umzubenennenden (disambiguierten) 
Funktionsnamen beeinflussen. Aus Gründen der Übersichtlichkeit verzichten wir auf "simulta- 
nes" Umbenennen von Sorten und Funktionen, MakeConsistent behandelt Sorten und Funktionen 
nacheinander: 



MakeConsistent: MODULE x ORIGIN-FUNC 

— .MODULE X ORIGIN-FUNC 



MakeConsistentimodule, originfunc) erhält ein (normalisiertes) Modul module und 
eine Originfunktion originfunc deren Wertebereich zwecks Durchführung von Ver- 
deckung oder Änderung des Exportverhaltens von Namen manipuliert wurde. Unter 
Zuhilfename der Funktionen GetSpecName und GetRenaming berechnet sie ein kon- 
sistentes Tupel {module'" , originfunc"). Durchgeführt werden Umbenennung von Na- 
men (e SPEC-NAME) in module und im Definitionsbereich von originfunc, sowie der 
Austausch von Sortennamen und Funktionsdeklarationen zwischen der public- und 
p r i va t e-Signatur. 
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renaming '.= GetRenaming{originfunc, {"label", "variable", "sort"}) 

Berechne module' durch Ersetzen der Sorten-, Variablen- und Markennamen in modu- 
le nach Maßgabe von renaming. 

Berechne originfunc' durch Ersetzen der Sorten-, Variablen- und Markennamen im 
Definitionsbereich von originfunc nach Maßgabe von renaming. Betroffen sind insbe- 
sondere auch die Sortenvektoren der disambiguierten Funktionsnamen. 

renaming' '.= GetRenaming{originfunc' , {"f unction"}) 

Berechne module" und originfunc" durch Ersetzen der Funktionsnamen in module' und 
im Definitionsbereich der Originfunktion originfunc' nach Maßgabe von renaming'. 

module'" entsteht aus module" durch Aktualisierung der public- und private- 
Signatur. Namen mit Sichtbarkeitsstufe "private" oder "hidden" sind nicht ex- 
portfähig und gehören in die private-Signatur. Solche mit Sichtbarkeitsstufe 
"public" hingegen gehören in die pubiic-Signatur. Parameter bleiben wo sie sind, 
nämlich in der parameter-Signatur. 

Rückgabewert: {module'", originfunc") 



6.2.2 Kombination von Modulen 



Der Import sowie das Binden von Parametern an Signatumamen eines Moduls führt bei der 
Normalisierung dazu, daß mehrere general forms zu einer neuen general form zusammengefaßt 
werden müssen. Diese Aufgabe erledigen die drei Funktionen Combineimports, CombineWith- 
Imports und CombineWithActModule. Als Hilfsfunktion greifen sie auf CombineDependencies 
und AdaptVisibility, welche die notwendigen Sichtbarkeitsanpassungen vornimmt, zu. 

AdaptVisibility kann als Identifikationsregel gelesen werden, die beim Kombinieren mehrerer 
Module festlegt, wann (disambiguierte) Namen miteinander identifiziert werden dürfen und unter 
welchen Umständen es zu Namenskonflikten kommt. Wegen der Overloading-Fähigkeit ist hier- 
bei von Wichtigkeit, daß zuerst alle Sortenidentifikationen vorgenommen werden (Aufruf von 
AdaptVisibility mit symboltypes := {"sort"}). Erst danach können die Funktionsidentifikatio- 
nen korrekt durchgeführt werden {symboltypes := {"f unction"}). Die Zweistufigkeit reduziert 
den Sortenvektortest auf syntaktische Gleichheit. Andernfalls müßten beim Test auf Identifizier- 
bareit die Argumentsorten der (disambiguierten) Funktionsnamen komponentenweise (rekursiv) 
auf Identifizierbarkeit geprüft werden. Analog zur sogenannten "Originrule" aus ASF können wir 
die ASF+ zugrundeliegende Identifikationsregel folgendermaßen beschreiben: 
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Identifikationsregel: Die (disambiguierten) Namen (namei, sortvi) und (name2, sortV2) aus 
zwei zu kombinierenden Modulen sind genau dann zu identifizieren, wenn 

• die ihnen zugeordneten Origins in den ersten drei Komponenten übereinstimmen, 

• die 4. Komponenten der Origins übereinstimmen oder eine 4. Komponente den Wert "hidden", 
die andere 4. Komponente dagegen "private" oder "public" enthält und 

• die in sortvi und sortV2 enthaltenen Argumentsorten (nur bei Funktionsnamen relevant) 
miteinander identifiziert werden können. 

Man beachte, daß diese Definition nicht eigentlich rekursiv ist, da der Rückbezug nicht wiederum 
selbst rückbezüglich ist. 

Zwischen den disambiguierten Namen {namei, sortvi) und {name2, sortv2) aus zwei zu 
kombinierenden Modulen kommt es genau dann zum Konflikt, wenn 

• sie nicht miteinander identifiziert werden können, obwohl 

• namei mit name2 übereinstimmt und 

• die in sortvi und sortV2 enthaltenen Argumentsorten miteinander identifiziert werden können. 

Wir führen noch eine Sprechweise ein, die sich bei der Behandlung von Parameterbindungen 
als nützlich erweisen wird. 

Seien originfi und originf2 zwei Originfunktionen. Sei {namei, sortvi) aus dem Defini- 
tionsbereich von originfi '^^^ {name2, sortv2) aus dem Definitionsbereich von originf2- Wir 
definieren: {namei, sortvi) referenziert bezüglich originfi dasselbe Objekt wie {name2, sortv2) 
bezüglich originf2 (im Zeichen: {namei, sortvi)/ originfi ~ {name2, sortv2)/ originf2) genau 
dann, wenn 

• die ihnen zugeordneten Origins in den ersten drei Komponenten übereinstimmen und 

• die in den Komponenten von sortvi und sortV2 enthaltenen Argumentsorten (nur bei Funk- 
tionsnamen relevant) jeweils dasselbe Signaturobjekt referenzieren. 

Die Identifikationsregel aus ASF+ identifiziert also Namen, die das gleiche Signaturobjekt 
referenzieren und deren Exportverhalten in den Importbefehlen nicht widersprüchlich festgelegt 
wird. 



AdaptVisibility: P(NF) x P({"label", "variable", "sort", "function"}) 
P(NF) 



AdaptVisibility(normalforms, symboltypes) sorgt für die Angleichung der Sichtbarkeit 
von Sorten- ("sort" e symboltypes) und Funktionsnamen ("f unction" e symbolty- 
pes) aus verschiedenen (NF-) Modulen. Gleichzeitige public- und private-Importe 
eines Namens weisen auf einen Spezifikationsfehler hin, weil ein Name entweder expor- 
tierbar oder nicht-exportierbar sein kann aber nicht beides gleichzeitig. 
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Sei {{modi, originfi, depf^) \ 1 <i < p} — normalforms 

Für i := 1 bis p wiederhole 

Für j := i + 1 bis p wiederhole 

Für alle {{namei, sortVi), {unamei, modinamei, symboltypci, visibilityi)) e originfi 
wiederhole 

Für alle {{namej, sortVj), {unamej, modinamej, symboltypcj, visibility j)) e ori- 
ginfj wiederhole 

/* Alle Origins aller übergebenen Originfunktionen originfi werden mit 
allen Origins aller anderen übergebenen Originfunktionen originfj ver- 
glichen. */ 

Falls {symboltypci G symboltypes) und 
sortVi = sortVj und unamei = unamej 

Falls modinamei = modinamej 

Falls symboltype^ ^ symboltype j 

SPEZIFIKATIONSFEHLER 

/* Beide disambiguierten Namen verdanken ihre Existenz der- 
selben Definition */ 

Falls {visibilityi = "hidden" und visibilityj e {"public", 
"private"}) 

Setze (mit Änderung von originfi) visibilityi '■= visibilityj 

Sonst falls {visibilityj = "hidden" und visibilityi £ {"public", 
"private"}) 

Setze (mit Änderung von originfj) visibilityj := visibilityi 

Sonst falls visibilityi 7^ visibilityj 

EXPORTIERBARKEITS-KONFLIKT 

Sonst falls namei = namej 

r Der disambiguierte Name {namei, sortVi) tritt in beiden Nor- 
malformen mit unterschiedlicher Bedeutung auf. */ 
NAMENSKONFLIKT 

Für alle i e {1,. . .,p} 

{mod'i, originf'^, depf[) := MakeConsistent{modi, originfi, depfi) 

Rückgabewert: {{mod[, originfj, depf[) \ l<i <p} 
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CombineDependencies: 7'(DEPENDENCY-FUNC) 

DEPENDENCY-FUNC 

CombineDependenczes{{depf j \ j G A}) erzeugt aus den Dependenzfunktionen meh- 
rerer zu kombinierender general forms eine neue Dependenzfunktion depf'. 

I* Siehe Seite 24. */ 
Rückgabewert: depf 

Importe werden in ASF"*" eleminiert, indem zunächst die Normalformen der importierten Mo- 
dule berechnet werden. Diese werden nach Maßgabe der Importbefehle modifiziert und instanzi- 
iert (siehe dazu den folgenden Abschnitt 6.2.3) und anschließend untereinander kombiniert. Dafür 
zuständig ist die Funktion Combineimports: 

Combineimports: 7'(NF) 
— > NF 

CombineImports(normalforms) kombiniert mehrere Normalformen. 

normalforms :— AdaptVisibility{normalforms, {"label", "variable", "sort"}) 
normalforms" :— AdaptVisibility {normalforms' , {"function"}) 
Sei {{modi, originf^, depfi) \ i e A} — normalforms" . 
mod' :— |_J modi 

originf' := [J originf^ 

i€A 

Falls originf keine Funktion 
NAMECLASH 

depf' \— CombineDependencies{{depf i \ i e A}) 

Rückgabewert: {mod', origmf, depf) 

Mit Hilfe von Combineimports wird eine Normalform erzeugt, die alle importierten Module in 
sich vereint. Sie wird anschließend durch Anwendung der Funktion CombineWithlmports mit der 
general form des importierenden Moduls kombiniert. Hier sind keine Sichtbarkeitsanpassungen 
mehr notwendig: 



CombineWithlmports: GF x NF 

— > NF 
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Combine With Imports {{mod, originf, depf), {modi^^, originf .^^^, depf .^^^)) kombiniert 
die general form einer Modulinstanz mit einer Normalform, die aus allen von ihr im- 
portierten Modulen errechnet worden ist. 



mod' geht aus mod durch Löschen aller Importkonstrukte hervor. 

m,od," := mod' U mod;rr,p 

Der Modulname von mod" (erste Komponente) wird auf den für die Normalform von 
mod vorgesehenen Namen gesetzt. Dieser kann beispielsweise aus dem Modulna- 
men von mod durch Anhängen der Extension ".nf" gewonnen werden. 

originf' := originf U originf .^^^ 

Falls originf keine Funktion: NAMECLASH 

Sei nun modname der Modulname (1 . Komponente) von mod. 

depf' := { {modname, 0) } U 

{ {modiname, modinames U {modname}) \ 
{modiname, modinames) e depf -^^^ } 

Rückgabewert: {mod", originf, depf) 



Wird in einem Importbefehl die Bindung eines Parametertupels aus dem importierten Modul 
mod FORM an Namen eines Moduls modAcr vorgenommen, so erfordert die Auswertung das 

Kombinieren der zugehörigen Normalformen. Dieser implizite Import des Moduls modAcr in 
das Modul mod form unterscheidet sich von gewöhnlichen Importen, weil hierdurch ein Modul 
"nachträglich" in eine bereits bestehende Modulhierarchie eingepflanzt wird. 



CombineWithActModule: NF x MODINST-NAME x NF 

— > NF 



CombineWithActModule{{modj,omi, originf j,^^, depfj,^^), paradefmod, (mod/^cr, ori- 
ginf act, depf act)) "implantiert" die Normalform {modp^ci, originf j^ct, depf^cj) in die Nor- 
malform (moJpoRM, originf i^oRM, depf^^o^y). Dabei wird eine Abhängigkeit zwischen den 
Namensräumen des Moduls mod^cj und dem Namensraum der formalen Parameter para- 
defmod aus modj:omi hergestellt. Es wird davon ausgegangen, daß bereits alle Renamings 
in der Normalform des formalen Moduls und die Sichtbarkeitsanpassungen zwischen 
den Namen beider Normalformen durchgeführt worden sind. 

mod := moc? ACT U ?«oc?form 

Der Modulname modname von modfo^u (erste Komponente) wird in mod übernommen. 

originf := ongmf^^^^ U originf 

Falls originf keine Funktion: NAMECLASH 

depf'^i^j := { {modiname, modinames U {paradefmod} U depf fQ^fj^{paradefmod) \ 
{modiname, modinames) G depf } 
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depf := CombineDependencies{depf ^Qf^^, (/e])/^^) 
Rückgabewert: {mod, originf, depf) 



6.2.3 Modulmodifikationen in Importbefelilen 

Werden in einem Importbefehl Namen umbenannt, Parameter gebunden oder die Sichtbarkeit 
von Signaturnamen verändert, so führt das semantisch dazu, daß die Normalformen der zu im- 
portierenden Module modifiziert werden müssen, bevor sie zu einer einzigen Normalform zusam- 
mengefaßt werden können. Diese Aufgabe übernehmen die Funktionen Hide, Rename und Bind 
mit den Hilfsfunktionen InstanciateModlnstName, Instanciate, SeparateParaBlock, GetParame- 
terRenamings und CheckSemanticConditions. 

Ein wesentlicher Teil eines jeden Importbefehls sind die den Schlüsselworten "private : " 
und "public : " folgenden Listen von Signatumamen. Sie geben Auskunft über die Sichtbarkeit 
der vom importierten Modul exportierten Signatumamen. Mit Hilfe der Funktion Hide werden 
alle nicht exportierten Namen verdeckt und die Sichtbarkeit der exportierten Signatumamen den 
Vorgaben des Importbefehls angepaßt. 

Hide: NF x VISIBILITY-FUNC 
— > NF 



Hide((mod, originf, depf), visibilityf) verdeckt alle Namen mit Sichtbarkeits stufe 
"private". Namen mit Sichtbarkeitsstufe "public" werden auf die in visibilityf an- 
gegebene Sichtbarkeitsstufe gesetzt; ist keine Angabe vorhanden, erhalten sie die Sicht- 
barkeitsstufe "hidden". 



originf' :— { {dis-name, {uname, modinst, symboltype, visibility')) \ 

{dis-name, {uname, modinst, symboltype, visibility)) G originf 

A {{visibility G {"hidden", "parameter"} A visibility = visibility') V 

{visibility = "private" A visibility' = "hidden") V 

{visibility — "public" 

A {{uname ^ Dom{visibilityf) A visibility' = "hidden") V 

{uname G Dorr\{visibilityf) A visibility' — visibility f {uname))))) } 

{mod', originf") :— MakeConsistent{mod, originf') 
Rückgabewert: {mod', origmf", depf) 

Der kopierende Import aus ASF"*" basiert auf der Zuordnung der zu kopierenden (Signatur-) 
Namen zu neuen Namensräumen. Zu diesem Zweck werden neue Namensraumbezeichnungen 
generiert, die sich aus den alten Bezeichnungen und der Instanzbezeichnung des Importbefehls 
zusammensetzen. 
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InstanciateModlnstName: MODINST-NAME x INST-NAME 

— ^ MODINST-NAME 



InstanciateModInstName(modiname, iname) instanziiert die Namensraumbezeichnung 
modiname mit der Instanzbezeichnung iname. Wurde modiname bereits mit iname in- 
stanziiert, so liegt ein Spezifikationsfehler vor. 



Falls modiname e MODULE-NAME /* erste Instanziierung */ 

imodiname := modiname" [ "iname" ] " 

Sonst 

Sei modname" ["oldinames"] " = modiname 
Falls iname In oldinames enthalten ist 

SPEZIFIKATIONSFEHLER! 
imodiname '.= modname" ["oldinames" , "iname"] " 

Rückgabewert: imodiname 



Eine Normalform repräsentiert nicht nur ein normalisiertes Modul; Origin- und Dependenz- 
funktion erlauben die Rekonstruktion der gesamten zugrundeliegenden Modulhierarchie. Werden 
Teile einer Normalform durch explizites Renaming oder Parameterbindung modifiziert, können 
die erforderlichen Instanziierungen auf die direkt betroffenen und die davon abhängigen Na- 
mensräume begrenzt werden. 



Instanciate: NF x RENAMING-FUNC x 7'(BINDING-BL0CK) x INST-NAME 
NF 



Instanciate((mod, originf, depf), renaming, bindingblocks, iname) instanziiert Namens- 
raumbezeichnungen in der Normalform (mod, originf, depf) mit der Instanzbezeichnung 
iname. Instanziiert werden die Bezeichnungen aller vom expliziten Renaming renaming 
und von den Parameterbindungen bindingblocks direkt betroffenen Namensräume, sowie 
alle bezüglich depf von ihnen abhängigen Namensräume. 

Sei {{binding,^, modnamei) \ i E Ä} = bindingblocks 

toinst := { modiname \ {{nam,e, *), (*, modiname^ *, *)) G originf A 

name G ÜQXW^renaming) U |^ ÜQXX\{hinding^) } 

toinst' :— toinst U {depf {modinst) \ modinst G toinst} 

Berechne {mod', originf, depf') durch Ersetzen jedes Auftretens einer Namensraum- 
bezeichnung modiname G toinst' 

• in mod (überall dort, wo sie Teil eines verdeckten Namens ist), 
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• in originf (Im Definitionsbereich überall dort, wo sie Teil eines verdeckten Na- 
mens ist und in der 2. Komponente der Origins des Wertebereichs) und 

• in depf (wo immer sie auftritt) 

durch InstanciateModInstName{modiname, iname). 
Rückgabewert: {mod', originf, depf) 



Rename: NF x RENAMING-FUNC 
— > NF 



Rename((mod, originf, depf), renaming) führt explizites Renaming durch, renaming 
enthält die Umbenennungen aller Renaminganweisungen des Importbefehls. 



Sei ren{x) :— 



falls {x, y) e renaming 
sonst 



und reu' die Erweiterung von reu auf Sortenvektoren: 

ren'{{sortni, . . . , sortnn)) '■= {ren{sortni) , . . . , ren{sortnn)) 

mod' wird aus mod durch syntaktisches Ersetzen aller Signaturnamen name durch 
ren{name) erzeugt. Man beachte daß ren nur Einfluß auf sichtbare Namen (e 
USER-NAME) hat. 

SPEZIFIKATIONSFEHLER falls mod' keine korrekte Signatur enthält. 
/* Ursache kann hier ein fehlerhafter Renamingbefehl sein, der dazu führt, daß ur- 
sprünglich verschiedene Namen des gleichen Namensraumes nach Durchführung 
des Renamings zusammenfallen. Renamings dieser Art können Funktionen mit glei- 
chen disambiguierten Namen aber unterschiedlichen Zielsorten erzeugen. 7 

originf' := { {ren{name), ren' (sortv)), {uname' , modiname, symboltype, visibility)) \ 
{{name, sortv), {uname, modiname, symboltype, visibility)) G originf A 
{{visibility — "hidden" A uname' — uname) V 
{visibility ^ "hidden" A uname' — ren{uname))) } 

Rückgabewert: {mod' , originf' , depf) 



Alle folgenden Funktionen dieses Abschnitts behandeln die Auswertung einer Parametertu- 
pelbindung. Der Trivialfunktion SeparateParaBlock und der (etwas technischen) Hilfsfunktion 
GetParameterRenamings folgen die Hauptfunktionen CheckSemanticConditions und Bind. Die 
Komplexität der Funktionen folgt aus der Tatsache, daß es sich bei jeder Parametertupelbindung 
um einen impliziten Import (also einen Import im Import) handelt und neben den schon betrach- 
teten Operationen (z. B. Verdecken von Namen, Instanziieren von Namensräumen) im Zuge des 
Testens semantischer Bedingungen und des Implantierens eines aktuellen Moduls in die bereits 
bestehende Modulhierarchie eines formalen Moduls eine Vielzahl neuer Rechenschritte erforder- 
lich sind. 
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SeparateParaBlock: NF x 7'(SPEC-NAME) 

— ^ NF X (SIG X P(CLAUSE)) x MODINST-NAME) 



SeparateParaBlock({mod, originf, depf), parameters) extrahiert aus der internen Mo- 
duldarstellung mod die Parametersignatur und -bedingungen der in parameters enthalte- 
nen Parameter eines Tupels. Die Parameter werden aus dem Definitionsbereich der Ori- 
ginfunktion entfernt und paradefinod der Namensraum zugewiesen, dem die Parameter 
angehören. SeparateParaBlock ist Hilfsfunktion von Bind. 



Seien sigp = die zu extrahierende Parametersignatur, 

conditions = die zu sig^ gehörenden Bedingungs[<lauseln und 

mod' = das IVIodul, das nach Entfernen von {sig^, conditions) aus mod entsteht. 

SPEZIFIKATIONSFEHLER, wenn l<eine Parametersignatur in mod enthalten ist, die 
genau alle Namen aus parameters enthält. 

Sei Parameter e parameters 

{*, paradefmod, *, *) := originf {parameter) 

r Welcher Parameter genommen wird, hat l<einen Einfluß auf paradefinod *l 

originf' :— { {{name, sortv), origin) \ 

{{name, sortv), origin) e originf A name ^ parameters } 

Rückgabewert: {{mod', originf', depf), {sig , conditions) , paradefmod) 



GetParameterRenamings: SIG x RENAMING-FUNC x ORIGIN-FUNC^ 

RENAMING-FUNC 



GetParameterRenamings{{sortSp, cons-decsp, ncons-decSp), hinding, originf f^^-^, 
originf j^^^^) berechnet die jenigen Namen, durch welche die nach der Vorschrift 
binding an Namen eines aktuellen Moduls zu bindenden formalen Parameter syn- 
taktisch ersetzt werden müssen. Die errechneten Namen sind im allgemeinen nicht 
mit denen aus H3r\{binding) identisch, weil alle Namen aus dem aktuellen Modul 
beim impliziten Import verdeckt werden, sofern sie nicht bereits im formalen Modul 
sichtbar sind. Als Argumente werden die Signatur des zu bindenden Parametertupels 
{sortSp,cons-decSp,ncons-decSp), die Bindungsvorschrift binding, die Originfunktion 
des aktuellen Moduls originf und eine weitere Originfunktion originf die 
aus originf j^^^. durch Setzen aller Namen auf die beim impliziten Import angestrebte 
Sichtbarkeitsstufe hervorgeht, übergeben. 

Falls {{binding {sortpar),0) \ sortpar e sortSp} % Dom{originf f^i^j) 

SPEZIFIKATIONSFEHLER /* Sortenparameterbindung fehlerhaft. Aktuelle 

Sorten existieren nicht im aktuellen Modul */ 
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sortpar-renaming :— 

{ {sortpar, name) \ sortpar e sortSp A 

{name,0) G Dom{originf A 

{name, 0) / originf ~ {binding (sortpar), 0) / originf f^^j^ } 



Sei sortsnp die Menge aller Sortennamen, die in den Deklarationen 
cons-decsp u ncons-decsp auftreten, aber nicht in sortSp enthalten sind. 

Falls {{sort,^) I sort e sortsnp} % Dom ( oh^'m/^cT-^v) 

SPEZIFIKATIONSFEHLER /* Da Funktionsparameter nur an aktuelle Funk- 
tionsnamen gleicher Deklaration gebunden 
werden können, müssen die Nicht-Parameter- 
Sortennamen der Funktionsparameterdekla- 
rationen nicht nur im formalen, sondern auch 
im aktuellen Modul auftreten. */ 

renaming : = 

{ {sortpar, binding {sortpar)) \ sortpar € sortSp } U 

{ {sort, name) \ sort G sorts^p A 

(name,0) G ÜOV(\{originf i^^j) A 

{name,^)/ originf^-j {sort,$)/originf^cj-^y } 

Berechne cons-decs'p und ncons-decSp aus cons-decsp und ncons-decsp durch Umbenen- 
nen aller Sorten nach Maßgabe von renammg. 

Sei disfuncSp = { {funcpar, sortv) \ {{funcpar, sortv), sort) G cons-decs'^VJncons-decs'p } 

Pd\\s {{binding{funcpar), soriv) \ {funcpar , sortv) G disfuncSp} % Dorr\{originf f^(,j) 

SPEZIFIKATIONSFEHLER /* Bindung der Funktionsparameter fehlerhaft, 

kein "wohlsortierter" aktueller Parameter vor- 
handen */ 

funcpar-renaming := 

{ {funcpar, name) \ 
{funcpar, sortv) G disfuncs^ A 
{name, sortv') G ÜOXT\{originf f^^j^i^^) A 

{name, sortv') / originf f^(,j_f^y ~ {binding {funcpar), sortv) / originf ^^^-^ } 

par-renaming :— sortpar-renaming U funcpar-renaming 
Rückgabewert: par-renaming 
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CheckSemanticConditions: 7'(CLAUSE) x MODULE^ x NF x PROVE-DB 



CheckSemanticConditions{conditions, mcxipoRM, '"^oc/actav! nform,^^^,prove-db) prüft, 
ob die semantischen Bedingungen, die an die Bindung von Parametern aus modpoRM an 
Namen des in nforrU/^^ enthaltenen aktuellen Moduls geknüpft wurden, erfüllt sind, con- 
ditions ist eine Menge von Gentzen-Klauseln, die aus den semantischen Bedingungen 
nach Ersetzen der formalen durch die aktuellen Parameter hervorgegangen ist. modAcx Av 
ist eine Variante des aktuellen Moduls, in der die Sichtbarkeit der Signatumamen an die 
Sichtbarkeit innerhalb des formalen Moduls angepaßt worden ist. 



Setze (*, *, *, *, *, '(^ar5or^/«nc,,„3,poRM, varsortfunc„^„.^„^^Q^^, *, *) := mod^oRu 

Setze (*, *, *, *, *, varsortfunc^„^^ ^cj-Av, varsortfunc„^„_^„^^^cj_^^, *, goals^^j,^^) modAci-Av 



varsortfunc^cT-A^:^ varsoHjunc^„,^^^cj-A,U varsortfunc„^„_,^„^^f,cT-Ay 



Für alle Gentzenklauseln condition e conditions 

Falls es nicht eine Gentzenklausel goal e goalSf^^j-Av und eine Variablensubstitution 
sub gibt mit: 

• sub{goal) = condition (Die Marken werden hier nicht berücksichtigt), 

• sub ist "sortenrein", d h. für alle {x, y) e sub gilt 

varsortfunCf,cj.t,^{x) = varsortfunc^o^y,{y) , 

• sub substituiert Konstruktor-Variablen mit Konstruktor-Variablen und Non- 
Konstruktor-Variablen mit Non-Konstruktor-Variablen, d. h. für alle {x,y) e sub 
gilt X e Dom(?;arsor^/Mnc,,„3,ACT-Av) V e üom{varsortfunc^„^^^a^J und 

• das zu goal korrespondierende Beweisziel in nform^^j (kann mit Hilfe des 
Markennamens bestimmt werden) gilt dort als bewiesen, dh. es gibt einen 
entsprechenden Beweis in pwve-db. 

SEMANTIC ERROR: Bevor die Spezifikation akzeptiert werden kann muß (falls 
noch nicht vorhanden) ein entsprechendes Beweisziel in das aktuelle Modul ein- 
gefügt und dessen Gültigkeit bewiesen werden. 

Rückgabewert: - 



50 



Bind: NF x RENAMING-FUNC x NF x PROVE-DB 

— ^ NF 



Bind{{nform^Q^^, binding, {mod^^cT, originf depf f^^^), prove-db) führt die Bindung 
eines Parametertupels durch. nforrrij^Q^ enthält das normalisierte, parametrisierte Mo- 
dul, dessen Parameter nach der Vorschrift binding an Namen des normalisierten Moduls 
mod^cT gebunden werden sollen. 



/* Zunächst werden alle Namen aus {mod^^ci, originf^^j, depf^^j) verdeckt. */ 

nform'^cT — Htde {{mod ;,ct , originff^cj: depf^cj):^) 

r AdaptVisibility ändert die Sichtbarkeit von Namen aus verschiedenen Modulen 
nach dem Prinzip der "maximalen" Sichtbarkeit. Angewandt auf nform^Q^^ und 
nform'^^^ bleibt nform^^^^ unverändert, weil es dort keinen Signaturnamen gibt, 
der in nform'^^j sichtbar ist. */ 



nforms :— AdaptVisibility {{nform'^i^j, ^fofm^Q^^}, {"label", "variable", "sort"}) 

{(modACT-Av, onginf^^j,^^, depf^cr-M)} := 

AdaptVisibility {nf orms, {"function"}) \ {nformpQf^^} 

((modpoRM, ongmfpof,^, depf^^^^), {sigp, conditions) , paradefmod) := 
Separater araBlock ( nform^Qp^^ , Dom ( binding) ) 

par-renaming := GetParameterRenamings{sigp, binding, originf/^^j, originf f^Qj_f^y) 

Berechne mod'^Qp^, originf'^^p^^ und conditions' aus moc^FORM, originf^Qp^^ und conditions 
durch Ersetzen der formalen Parameter nach Maßgabe von par-renaming. 

SPEZIFIKATIONSFEHLER falls mod'^^^^ keine korrekte Signatur enthält. 

/* Eine fehlerhafter Parameterbindung kann dazu führen, daß Funktionen mit glei- 
chen disambiguierten Namen und unterschiedlichen Zielsorten erzeugt werden. 

*/ 



CheckSemanticConditions{conditions' , modpopy,, modAciAv, 

{mod^T: originf^cT: depf ^^j), prove-db) 

nform^g^^^^ :— CombineWithActModule{{mod'^QP^, originf'^Q^^, depf^^^^j), paradefmod, 

(mociACT-Av, ortgmf^cT-Av^ depf ^^j-av)) 

Rückgabewert: nform,^^^^^ 
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6.2.4 Die Normalisierungsfunktionen NF und NormalForm 

Ziel dieses Abschnitts ist die Vorstellung einer Funktion NormalForm, die eine gegebene hierar- 
chische ASF+-Spezifikation in eine flache, nur aus einem Topmodul bestehende ASF+-Spezifikation 
transformiert. NormalForm besteht im wesentlichen aus einem Aufruf der rekursiven Funktion 
NF. NF ist die für das Verständnis des Algorithmus grundlegende Funktion. Weiterhin werden 
die Trivialfunktionen ModuleText, MakeGF und ExtemModRep benötigt. 



ModuleText: MODULE-NAME x ASF-SPEC 
— > ASF-MODULE 



ModuleTextimodname, spec) sucht ein Modul asf-module namens modname in spec. 
Falls kein solches Modul existiert: SPEZIFIKATIONSFEHLER! ModuleText ist Hilfs- 
funktion von NF. 



Weitere Formalisierung entfällt. 
Rückgabewert: asf-module 



MakeGF: ASF-MODULE 
^GF 



MakeGF(asf-module) berechnet aus einem isolierten nicht notwendig importfreien 
ASF^-Modul einer Spezifikation eine general form (mod, originf, depf). MakeGF ist 
Hilfsfunktion von NF. 



Der Wert von mod wird direl^t aus dem ASF-Modul ermittelt, es handelt sich hier 
lediglich um eine andere Repräsentationsform. 

Jedem (disambiguierten) Sorten- und Funktionsnamen aus der Signatur, jedem (di- 
sambiguierten) Parameternamen aus einer der Parametersignaturen und jedem, in- 
nerhalb des Moduls auftretenen (disambiguierten) Variablen- und Markennamen wird 
vermittels originf ein Origin zugeordnet.^ originf ist zunächst partiell in dem Sinn, daß 
importierte (Teil-) Signaturen noch nicht in Dom{originf) enthalten sind. 

depf ■.= ^ 
Rückgabewert: {mod, originf, depf) 



^Siehe dazu Seite 35 
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NF: MODULE-NAME x ASF-SPEC x PROVE-DB 
— > NF 



NF(modname, spec, prove-db) berechnet rekursiv die Normalform nform^^^^^^ der zum 
Modul namens modname zugehörigen general form. 

importing-gf := MakeGF{ModuleText{modname, spec)) 
Setze ((*, imports, . . .), *, *) :— importing-gf 

Sei {{modnamei, inamei, visibüityf ^, renaming^, bindingblockSj) \ i & Ä} — imports 

Für alle i e A 

nforrrij^ :— NF {modnamei, spec, prove-db) 
nform[ :— Hidelnform^, visibilityf i) 

Falls inamCi = A {renaming^ 7^ V bindingblocks^ ^ 0) 
SPEZIFIKATIONSFEHLER 

Falls inamCi 7^ 

nform" := Instanciate{nform[, renaming^, bindingblocks^, inamei) 

nform'l' := Rename{nform'- , renamingj) 

Für alle {hinding, modname f^cj) G bindingblocks^ wiederhole 

nform^Qj :— NF {modname t,cj, spec, prove-db) 

nform'l' :— Bind{nform'-' , binding, nform^^j, prove-db) 

nform,^^^^^ CombineWithImports{importing-gf, CombineImports{{nform'-' \ i G A})) 
Rücl<gabewert: nform,^^^^ 



ExternModRep: MODULE 

— > ASF-MODULE 



ExternModRep{module) berechnet die ASF+-Darstellung asf-module des Moduls Modu- 
le. Diese Funktion kann mit einer Option ausgestattet werden, die es erlaubt überladene 
Funktionsnamen durch eindeutige Repräsentationen ihrer disambiguierten Namen zu er- 
setzen. ExternModRep ist Hilfsfunktion von NormalForm. 



Weitere Formalisierung entfällt! 
Rückgabewert: asf-module 
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NormalForm: ASF-SPEC x PROVE-DB 
ASF-SPEC 



NormalForm(spec, prove-db) berechnet aus einer modularen ASF+-Spezifikation eine 
Spezifikation, bestehend aus einem einzigen (importfreien) Modul asf-module. Die Wis- 
sensbasis prove-db beinhaltet Informationen über gelungene Beweise und wird für die 
Überprüfung von semantischen Bedingungen gebraucht. 

Sei modname der Name des Topmoduls aus spec. 
{mod, originf, depf) := NF{modname, spec, prove-db) 

asf-module := ExtemModRep{mod) 



Rückgabewert: {asf-module, 0) 
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6.3 Ein Beispiel für ein normalisiertes Modul 

Um die Arbeitsweise des Normalformalgorithmus zu veranschaulichen geben wir schließlich 
noch das importfreie, durch Normalisierung erzeugte Modul OrdNatSequences . nf an. 



module OrdNatSequences . nf 
{ 

add signature 
{ 

public : 
sort s 

BOOL, NAT, NSEQ 
constructors 
true, false 

s 

Nnil 
cons 

non-constructors 

greater 
greater 



NAT 

NAT # NSEQ 

NAT # NAT 
NSEQ # NSEQ -> BOOL 



-> BOOL 
-> NAT 
-> NAT 
-> NSEQ 
-> NSEQ 

-> BOOL 



private : 

non-constructors 
Bo-and, Bo-or 
Bo-not 
_ Nat-+ _ 
Nat-eq 
ONat-geq 



BOOL # BOOL 
BOOL 

NAT # NAT 
NAT # NAT 
NAT # NAT 



-> BOOL 

-> BOOL 

-> NAT 

-> BOOL 

-> BOOL 



variables 

{ constructors 

Nat-x, Nat-y, Nat-u, 

ONat-x, ONat-y, ONat-u, ONat-v, 

OSeq-il, 0Seq-i2, 0Seq-i3 : -> NAT 

OSeq-seql, 0Seq-seq2, OSeq-sl, 0Seq-s2 : -> NSEQ 
non-constructors 

Bo-x, Bo-y : -> BOOL } 

equat Ions 
{ 

macro-equation Bo-and (Bo-x, Bo-y ) 
{ 

case 

{ ( Bo-x @ true ) : Bo-y 

( Bo-x @ false ) : false } 



} 



macro-equation Bo-not (Bo-x) 
{ 

case 

{ ( Bo-x @ true ) : false 
( Bo-x @ false ) : true } 

} 

[Bo-el] Bo-or(Bo-x, Bo-y) = 

Bo-not (Bo-and (Bo-not (Bo-x) , Bo-not (Bo-y) ) ) 

macro-equation (Nat-x Nat-+ Nat-y) 
{ 

case 

{ ( Nat-y @ ) : Nat-x 

( Nat-y @ s(Nat-u) ) : s (Nat-x Nat-+ Nat-u) } 

macro-equation Nat-eq (Nat-x, Nat-y) 
{ if ( Nat-x = Nat-y ) true 

eise false } 

} 

macro-equation greater (ONat-x, ONat-y) 
{ 

case 

{ ( ONat-x @ ) : false 

( ONat-x @ s (ONat-u) , ONat-y @ ) : true 
( ONat-x @ s (ONat-u) , ONat-y @ s (ONat-v) ): 
greater (ONat-u, ONat-v) } 

} 

[ONat-el] ONat-geq (ONat-x, ONat-y) = 

Bo-or (greater (ONat-x, ONat-y) , eq (ONat-x, ONat 



macro-equation greater (OSeq-seql , 0Seq-seq2) 



{ 



case 
{ 

( 
( 



/ -k lex-order of sequences */ 



OSeq-seql 
OSeq-seql 

0Seq-seq2 
OSeq-seql 
0Seq-seq2 



@ Nnil ) 

@ cons (OSeq-il , 

@ Nnil 

@ cons (OSeq-il , 

@ cons (0Seq-i2 , 



OSeq-sl) 

OSeq-sl) 
0Seq-s2) 



if ( greater (OSeq-il , 0Seq-i2) 
true 



false 



true 



56 



eise if ( OSeq-il = 0Seq-i2 ) 

greater (OSeq-sl, 0Seq-s2) 
eise false 



} 

} 



} 



goals 
{ 

[ONat-irref] greater (ONat-x, ONat-x) 
— > 

[ONat-trans] greater (ONat-x, ONat-u) , greater (ONat-u, ONat-y) 
— > greater (ONat-x, ONat-y) 

[ONat-total] 

— > greater (ONat-x, ONat-y) , greater (ONat-y, ONat-x) , 
ONat-x = ONat-y 

} 

} /* OrdNatSequences . nf */ 



7 Abschließende Zusammenfassung 
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Mit ASF"*" ist es gelungen, eine algebraische Spezifikationssprache zu entwickeln, die neue Kon- 
zepte wie beispielsweise das differenzierte Verdecken von Signaturnamen, semantische Bedin- 
gungen an Parameter und die Angabe von Beweiszielen in sich vereint, ohne dabei auf wesent- 
liche Elemente der bereits existierenden Sprache ASF verzichten zu müssen. Hierbei konnte die 
Syntax von ASF sogar noch vereinfacht werden. 

ASF+ ist jedoch mehr als eine nur um zusätzliche Konstruke erweiterte Version von ASF. 
Grundsätzliche Untersuchungen (wie in Kapitel 4 dargestellt) deckten Fehler in der Semantik 
von ASF auf und führten zu den Begriffsbildungen "benutzender" und "kopierender Import". 
Während der benutzende Import aus ASF übernommen wurde, verhindern in ASF+ von den 
kopierenden Importbefehlen zur Verfügung gestellte Instanzbezeichnungen Namensverwechse- 
lungen zwischen dem manipulierten Modul und seinem Original. 

Wesentlicher Bestandteil von ASF+ ist das Namensraumkonzept, welches jedem Signatur- 
namen bei seiner Definition den Modulnamen zuordnet. Während beim benutzenden Import der 
Namensraum unverändert bleibt, führt der kopierende Import eines Namens zur Instanziierung 
des zugeordneten Namensraumes. Bei der Kombination mehrerer Module zu einem Normalform- 
modul werden nur solche Namen identifiziert, die dem gleichen Namensraum angehören. 

Das Namensraumkonzept spielt auch in der Semantik verdeckter Namen eine wichtige Rolle. 
Jedem zu verdeckenden Namen wird im Zuge der Normalisierung die (abgekürzte) Namensraum- 
bezeichnung vorangestellt. Dies erhöht die Verständlichkeit des erzeugten Normalformmoduls 
und macht den modularen Aufbau der Spezifikation sichtbar. 

Der Preis für die Verbesserungen ist jedoch eine gewisse Verkomplizierung der Normali- 
sierungsprozedur, was beim Vergleich des im Kapitel 6 vorgestellten Algorithmus mit dem aus 
[Bergstra&al.89] (Seite 23-28) deutUch wird. 

Schließlich erlauben die von uns entwickelten Strukturdiagramme eine ebenso informative 
wie leicht verständliche Darstellung von ASF+-Spezifikationen. Diese Strukturdiagramme eig- 
nen sich darüberhinaus auch dazu, ein korrektes intuitives Verständnis für die wesentlichen Kon- 
zepte der Normalisierungsprozedur — wie Originfunktion, Dependenzfunktion, Sichtbarkeitsan- 
passung, Renaming, Parameterbindung, Namensrauminstanziierung, etc. — zu vermitteln. 
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